Thread safety of File functions. - C++ Language (Moderated)

C++Talk.NET
C++ language newsgroups

Archives

FAQ

Memberlist

Usergroups

Profile

Thread safety of File functions.
Goto page 1, 2 Next

C++Talk.NET Forum Index -> C++ Language (Moderated)

View previous topic :: View next topic

Author

Message

Dhruv
Guest

Posted: Mon Jan 26, 2004 2:45 pm Post subject: Thread safety of File functions.

Are the standard file functions defined <cstdio> thread safe? I'm mainly interested in fread and fwrite. Also, I'd like to know whether these functions need to be defined in the std:: namespace? That's because g++3.2 lets me use these functions without std:: qualification. Regards, -Dhruv. [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]

Matthew Wilson
Guest

Posted: Tue Jan 27, 2004 10:49 am Post subject: Re: Thread safety of File functions.

"Dhruv" <dhruvbird (AT) gmx (DOT) net> wrote

Quote:

Are the standard file functions defined <cstdio> thread safe?

The C++-98 standard says nothing about threads. The only occurence of
the word thread is in 15.1;2 and this is talking about thread of
control for exception handling.

Quote:

I'm mainly interested in fread and fwrite.

Notwithstanding the C++ (and C) standards being silent on threading,
the underlying OS file-handling will be thread-safe, so I'd be pretty
surprised if your implementations were not also thread safe. But
anything's possible ...

Quote:

Also, I'd like to know whether
these functions need to be defined in the std:: namespace?

You can include (as I do; lazy old dog) stdio.h and use them
unqualified, or include <cstdio> and have to qualify them.

Quote:

That's because
g++3.2 lets me use these functions without std:: qualification.

If you include cstdio and can still use them unqualified, my guess
would be that that is non-standard behaviour, but I'm not an expert on
this kind of thing

Cheers

Matthew Wilson

STLSoft moderator
(http://www.stlsoft.org)
Contributing editor, C/C++ Users Journal
(www.synesis.com.au/articles.html#columns)

"I can't sleep nights till I found out who hurled what ball through
what apparatus" -- Dr Niles Crane

-------------------------------------------------------------------------------

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Jeff Greif
Guest

Posted: Tue Jan 27, 2004 11:07 am Post subject: Re: Thread safety of File functions.

"Dhruv" <dhruvbird (AT) gmx (DOT) net> wrote

Quote:

They are extern "C" functions and are in the global namespace. Their names
may not be mangled by the compiler or require any namespace qualification to
be used, because they must be usable from C.

Jeff

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Jack Klein
Guest

Posted: Tue Jan 27, 2004 2:59 pm Post subject: Re: Thread safety of File functions.

On 26 Jan 2004 09:45:08 -0500, "Dhruv" <dhruvbird (AT) gmx (DOT) net> wrote in
comp.lang.c++.moderated:

Quote:

Are the standard file functions defined <cstdio> thread safe?

Yes. No. Maybe. Neither the C nor C++ standard defines or supports
any sort of multiple simultaneous execution model at this time. There
is some talk of adding such support to a future version of the C++
standard. As far as I know there is no plan to consider this for
future versions of the C standard.

In any case, whether a particular platform supports multiple threads
of execution at all is determined by the underlying operating system,
not the language. Whether an implementation for a platform that
supports multiple threads of execution provides library functions that
are thread safe is strictly an implementation specific detail, not one
addressed by the current standard of either language.

Quote:

According to the C++ standard, including C headers with the <cxxx>
rather than <xxx.h> notation places all identifiers except macros in
namespace std. On the other hand, both C and C++ allow any C library
function to be provided as a macro, and macros are not restricted to
namespaces.

So if your compiler provides macros for fread and fwrite they can be
accessible without std::. If there are no macro versions provided,
only actual functions prototyped in the header, they should not be in
the global namespace.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

kanze@gabi-soft.fr
Guest

Posted: Tue Jan 27, 2004 6:37 pm Post subject: Re: Thread safety of File functions.

"Dhruv" <dhruvbird (AT) gmx (DOT) net> wrote

Quote:

Are the standard file functions defined <cstdio> thread safe?

There is no such thing as a thread in the C++ standard. If you are
using threads, you will have to check with the relevant standard.
(Posix requires all of the functions in <stdio.h> to be thread safe. It
would take a really perverse implementation to conform to this, and yet
have non-thread-safe versions in <cstdio>. As for Windows, I don't
know. If anyone knows of a link equivalent to
http://www.unix-systems.org/single_unix_specification/, but for Windows,
I'd love to hear about it.)

Quote:

If you include <stdio.h>, they should be available in the global
namespace. If you include <cstdio>, they should be available in std::.
I'm not sure, however, that the standard forbids their also being
available in the global namespace.

In practice, the way to go is to use <stdio.h>, and consider that they
are available in global namespace. This has the advantage of working
with older compilers as well.

--
James Kanze GABI Software mailto:kanze (AT) gabi-soft (DOT) fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Alexander Terekhov
Guest

Posted: Tue Jan 27, 2004 6:38 pm Post subject: Re: Thread safety of File functions.

Matthew Wilson wrote:
[...]

Quote:

Under POSIX they're "strongly" thread-safe (and that's rather brain-
damaged). And they're in violation of the C++ standard with respect
to nothrow contract (if you happen to use thread cancellation).

regards,
alexander.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Ben Hutchings
Guest

Posted: Wed Jan 28, 2004 10:20 am Post subject: Re: Thread safety of File functions.

Jack Klein wrote:
<snip>

Quote:

According to the C++ standard, including C headers with the <cxxx
rather than namespace std. On the other hand, both C and C++ allow any C library
function to be provided as a macro, and macros are not restricted to
namespaces.
snip

C library functions must not be implemented as macros in C++; they can
of course be inline functions - see 17.4.1.2/6 and footnote 159. (It's
not clear to me that the normative text actually implies this but the
footnote makes it clear that that's the intent.)

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

P.J. Plauger
Guest

Posted: Wed Jan 28, 2004 1:24 pm Post subject: Re: Thread safety of File functions.

"Jack Klein" <jackklein (AT) spamcop (DOT) net> wrote

Quote:

Actually, the C++ Standard requires that <xxx.h> headers first declare
names in namespace std, then hoist them into the global namespace with
a using declaration. But many implementations don't do that.

Quote:

On the other hand, both C and C++ allow any C library
function to be provided as a macro, and macros are not restricted to
namespaces.

So if your compiler provides macros for fread and fwrite they can be
accessible without std::. If there are no macro versions provided,
only actual functions prototyped in the header, they should not be in
the global namespace.

Uh, no. C++ explicitly disallows the macro overrides for functions
that C permits.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

kanze@gabi-soft.fr
Guest

Posted: Wed Jan 28, 2004 8:21 pm Post subject: Re: Thread safety of File functions.

Jack Klein <jackklein (AT) spamcop (DOT) net> wrote

[...]

Quote:

I'm mainly interested in fread and fwrite. Also, I'd like to know
whether these functions need to be defined in the std:: namespace?
That's because g++3.2 lets me use these functions without std::
qualification.

According to the C++ standard, including C headers with the <cxxx
rather than namespace std. On the other hand, both C and C++ allow any C library
function to be provided as a macro, and macros are not restricted to
namespaces.

§17.4.1.2/6: "Names that are defined as functions in C shall be defined
as functions in the C++ standard library." With the note: "This
disallows the practice, allowed in C, of providing a "masking macro" in
additon to the function prototype. The ohnly way to achieve equivalent
"inline" behavior in C++ is to provide a definition as an extern inline
function."

--
James Kanze GABI Software mailto:kanze (AT) gabi-soft (DOT) fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Jack Klein
Guest

Posted: Thu Jan 29, 2004 10:04 am Post subject: Re: Thread safety of File functions.

On 28 Jan 2004 08:24:03 -0500, "P.J. Plauger" <pjp (AT) dinkumware (DOT) com>
wrote in comp.lang.c++.moderated:

Quote:

"Jack Klein" <jackklein (AT) spamcop (DOT) net> wrote in message
news:67rb10hn803bqnnbtnjsnvdibf80iqne3d (AT) 4ax (DOT) com...

I'm mainly interested in fread and fwrite. Also, I'd like to know
whether
these functions need to be defined in the std:: namespace? That's
because
g++3.2 lets me use these functions without std:: qualification.

According to the C++ standard, including C headers with the <cxxx
rather than namespace std.

Actually, the C++ Standard requires that <xxx.h> headers first declare
names in namespace std, then hoist them into the global namespace with
a using declaration. But many implementations don't do that.

I think that either I miswrote or you misread my reply. I was talking
about C headers included with the <cxxx> notation, and my reading of
the C++ standard implies that an implementation is not allowed to
place them into the global namespace.

Quote:

Yes, I have just noticed that based on the foot note that Ben
Hutchings pointed out. That is rather bizarre, because the text of
the normative statement does not require the restriction of the foot
note.

The normative text is "Names that are defined as functions in C shall
be defined as functions in the C++ Standard Library." This can be
implemented without disallowing "the practice, allowed in C, of
providing a "masking macro" in addition to the function prototype."

The C standard does, and always has, required that the function exist
and be accessible by name by suppressing the macro, with a #undef
directive or by surrounding it with parentheses.

I don't understand the reasoning for forbidding the additional macro
implementation. Can you explain it?

BTW, I still miss your column in my copy of Embedded Systems
Programming every month.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

kanze@gabi-soft.fr
Guest

Posted: Sat Jan 31, 2004 1:12 am Post subject: Re: Thread safety of File functions.

Jack Klein <jackklein (AT) spamcop (DOT) net> wrote

Quote:

The normative text is "Names that are defined as functions in C shall
be defined as functions in the C++ Standard Library." This can be
implemented without disallowing "the practice, allowed in C, of
providing a "masking macro" in addition to the function prototype."

The wording in the normative part is not very good. It would be better
if it said explicitly that the macros cannot exist, since this is the
intent.

Quote:

The C standard does, and always has, required that the function exist
and be accessible by name by suppressing the macro, with a #undef
directive or by surrounding it with parentheses.

I don't understand the reasoning for forbidding the additional macro
implementation. Can you explain it?

It allows you to do things like:

class MyAllocator
{
public:
void* alloc( size_t n ) ;
void free( void* p ) ;
} ;

If free could be a macro (as it can be in C), you'd be in deep trouble.

The liberty for the functions to be macros in C was based 1) on
performance considerations, and 2) on the fact that the user couldn't
define a function with the same name anyway, because all functions must
be at global scope. Inline functions render 1 largely caduc, and the
presence of class member functions and namespaces means that the cost of
allowing macros is far, far higher than in C.

--
James Kanze GABI Software mailto:kanze (AT) gabi-soft (DOT) fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Allan W
Guest

Posted: Tue Feb 03, 2004 11:41 am Post subject: Re: Thread safety of File functions.

Quote:

"Dhruv" <dhruvbird (AT) gmx (DOT) net> wrote
Are the standard file functions defined <cstdio> thread safe?

[email]kanze (AT) gabi-soft (DOT) fr[/email] wrote

Quote:

The header files are always the same, but the implementation depends
on
compile-time settings in the compiler, which includes options that are
passed to the linker. Your choices are:
* Single-threaded or Multiple-threaded
* Debuger symbols as part of the executable, or not
* Link to a DLL or not (you would have to distribute the DLL with
your app)
Note that you cannot link to the single-threaded DLL, because there's
only one DLL and it is multi-threaded.

Quote:

If anyone knows of a link equivalent to
http://www.unix-systems.org/single_unix_specification/, but for Windows,
I'd love to hear about it.)

I didn't read the whole thing -- it is the spec of what an OS has to
provide, in order to call it Unix? Windows are (is?) proprietary, so
you're never going to find it to the same level of detail.

The best documentation I am aware of isn't available online. The
Charles
Petzold books originally described the Windows API's pretty well. For
more
modern features, you could look at the documentation that comes with
Visual
Studio; much (but not all) of this is free online at
http://msdn.microsoft.com.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

kanze@gabi-soft.fr
Guest

Posted: Wed Feb 04, 2004 10:38 am Post subject: Re: Thread safety of File functions.

[email]allan_w (AT) my-dejanews (DOT) com[/email] (Allan W) wrote in message
news:<7f2735a5.0402021621.7707cc9e (AT) posting (DOT) google.com>...

Quote:

"Dhruv" <dhruvbird (AT) gmx (DOT) net> wrote
Are the standard file functions defined <cstdio> thread safe?

[email]kanze (AT) gabi-soft (DOT) fr[/email] wrote
There is no such thing as a thread in the C++ standard. If you are
using threads, you will have to check with the relevant standard.
(Posix requires all of the functions in <stdio.h> to be thread
safe. It would take a really perverse implementation to conform to
this, and yet have non-thread-safe versions in <cstdio>. As for
Windows, I don't know.

The header files are always the same, but the implementation depends
on compile-time settings in the compiler, which includes options that
are passed to the linker.

I suspect that this is in fact true for many Unix implementations.
Generally speaking you must pass some sort of information to the
compiler to tell it that the application is multithreaded. The compiler
can then use this information to choose between versions of the
libraries to link in. (I know that Sun's C++ compiler does this for the
C++ libraries; I presume that the same thing holds for C.)

Quote:

Your choices are:
* Single-threaded or Multiple-threaded
* Debuger symbols as part of the executable, or not
* Link to a DLL or not (you would have to distribute the DLL with
your app)
Note that you cannot link to the single-threaded DLL, because there's
only one DLL and it is multi-threaded.

I've a total of five variants for libc (a mixture of the platform
specific API and much of the standard C library) on my Sparc (under
Solaris). The basic variants here are single or multi-threaded, 32 or 64
bits, and dynamic or static linking. And some are missing; don't ask me
to explain the logic behind which are there and which aren't.

Quote:

If anyone knows of a link equivalent to
http://www.unix-systems.org/single_unix_specification/, but for Windows,
I'd love to hear about it.)

I didn't read the whole thing -- it is the spec of what an OS has to
provide, in order to call it Unix?

It's somewhat complicated, as it is a common document for the Posix
standards and the Open Group technical standards. Legally, to be called
Unix, a system must comply with the Open Group technical standards, and
have signed a trademark agreement with the Open Group. The trademark
agreement sets out a certain number of technical requirements;
conformance to the Open Group technical standard is one. (There are
also fees and royalties, which explains why Linux will never be a Unix.
And why I prefer to speak of Posix compliant systems, at least with
regards to threading, than of Unix.)

Note too that both Posix and Open Group have optional parts -- threading
is one of them.

Quote:

Windows are (is?) proprietary, so you're never going to find it to the
same level of detail.

Unix is proprietary as well:-). (And strictly speaking, Windows isn't,
since it is a generic name for MS-Windows, X Windows, etc. But we all
know which one we mean when we just say Windows.)

Quote:

I'm aware of some online documentation from Microsoft, but it seems more
tutorial, or at the most, at the level of early Unix man pages (which
leave a lot of things open). I was unable to find anything concerning
memory synchronization there, for example. (One current question: what
are the synchronization rules concerning memory "mapped into" the
process as a result of a dlopen/LoadLibrary? Even the Posix standard is
pretty silent concerning that one.)

--
James Kanze GABI Software mailto:kanze (AT) gabi-soft (DOT) fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Ben Hutchings
Guest

Posted: Thu Feb 05, 2004 11:45 am Post subject: Re: Thread safety of File functions.

[email]kanze (AT) gabi-soft (DOT) fr[/email] wrote:

Quote:

allan_w (AT) my-dejanews (DOT) com (Allan W) wrote in message
news:<7f2735a5.0402021621.7707cc9e (AT) posting (DOT) google.com>...
snip

[ [email]kanze (AT) gabi-soft (DOT) fr[/email] wrote:]

Quote:

If anyone knows of a link equivalent to
http://www.unix-systems.org/single_unix_specification/, but for Windows,
I'd love to hear about it.)
snip
Windows are (is?) proprietary, so you're never going to find it to the
same level of detail.

Unix is proprietary as well:-). (And strictly speaking, Windows isn't,
since it is a generic name for MS-Windows, X Windows, etc. But we all
know which one we mean when we just say Windows.)

It probably isn't a trademark in English-speaking countries, but it
has been found to be a trademark in Benelux after Microsoft sued
Lindows and its distributors.

Quote:

The best documentation I am aware of isn't available online. The
Charles Petzold books originally described the Windows API's pretty
well. For more modern features, you could look at the documentation
that comes with Visual Studio; much (but not all) of this is free
online at http://msdn.microsoft.com.

I'm aware of some online documentation from Microsoft, but it seems more
tutorial, or at the most, at the level of early Unix man pages (which
leave a lot of things open). I was unable to find anything concerning
memory synchronization there, for example. (One current question: what
are the synchronization rules concerning memory "mapped into" the
process as a result of a dlopen/LoadLibrary? Even the Posix standard is
pretty silent concerning that one.)

I'm not sure what you mean about synchronisation rules. There are
general discussions of synchronisation and of memory management in
the Platform SDK:
<http://msdn.microsoft.com/library/en-us/dllproc/base/synchronization.asp>,
<http://msdn.microsoft.com/library/en-us/memory/base/memory_management.asp>.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

kanze@gabi-soft.fr
Guest

Posted: Fri Feb 06, 2004 7:57 pm Post subject: Re: Thread safety of File functions.

Ben Hutchings <do-not-spam-benh (AT) bwsint (DOT) com> wrote

Quote:

kanze (AT) gabi-soft (DOT) fr wrote:
[email]allan_w (AT) my-dejanews (DOT) com[/email] (Allan W) wrote in message
news:<7f2735a5.0402021621.7707cc9e (AT) posting (DOT) google.com>...
snip
[ [email]kanze (AT) gabi-soft (DOT) fr[/email] wrote:]
If anyone knows of a link equivalent to
http://www.unix-systems.org/single_unix_specification/, but
for Windows, I'd love to hear about it.)
snip
Windows are (is?) proprietary, so you're never going to find it
to the same level of detail.

Unix is proprietary as well:-). (And strictly speaking, Windows
isn't, since it is a generic name for MS-Windows, X Windows, etc.
But we all know which one we mean when we just say Windows.)

It probably isn't a trademark in English-speaking countries, but it
has been found to be a trademark in Benelux after Microsoft sued
Lindows and its distributors.

I seem to remember reading about a court case in America where the
trademark protection was refused, on the grounds that it was a generic
noun. Of course, the generic noun in France would be fenêtres, and not
windows, so perhaps...

Can Microsoft sue me if I ask someone to open the windows in a room? (I
don't live in an English speaking country, but I do occasionally use
English anyway.)

Quote:

The best documentation I am aware of isn't available online. The
Charles Petzold books originally described the Windows API's
pretty well. For more modern features, you could look at the
documentation that comes with Visual Studio; much (but not all)
of this is free online at http://msdn.microsoft.com.

I'm aware of some online documentation from Microsoft, but it seems
more tutorial, or at the most, at the level of early Unix man pages
(which leave a lot of things open). I was unable to find anything
concerning memory synchronization there, for example. (One current
question: what are the synchronization rules concerning memory
"mapped into" the process as a result of a dlopen/LoadLibrary?
Even the Posix standard is pretty silent concerning that one.)

I'm not sure what you mean about synchronisation rules. There are
general discussions of synchronisation and of memory management in the
Platform SDK:

http://msdn.microsoft.com/library/en-us/dllproc/base/synchronization.asp>,
http://msdn.microsoft.com/library/en-us/memory/base/memory_management.asp>.

I'm talking about file synchronization here. What the function fsych or
the options O_SYNC, O_DSYNC and O_RSYNC to open do under Posix. (I
don't know the equivalent requests under Windows, but I'm sure they
exist.)

C++ defines IO by reference to the corresponding functions in the C
standard. Where, for fclose and fflush, we have "Any unwritten buffered
data for the stream are delivered to the host environment to be written
to the file". In my experience, for serious applications, that isn't
enough. If the system goes down between the moment the data is
delivered to the host environment, and the moment it is physically
written, the data is lost.

Of course, synchronization isn't free -- on my system, a synchronized
write requires at least 10 milliseconds, where as a non-synchronized one
is several orders of magnitude faster. And you don't need it
everywhere; if I synchronized every write to the log file, my
application would be unusable. But until all of the application data
modified in a transaction has been synchronized to disk, I don't notify
the client that the work is finished.

There is no way to achieve this requirement using iostream (or FILE*).
This is one case where Java is better -- although it is fairly awkward
to use (you have to get the FileDescriptor of the FileOutputStream),
there is a standard function which can be called to ensure
synchronization.

(Of course, there's more to ensuring transactional integrety than just
synchronizing file writes.)

--
James Kanze GABI Software mailto:kanze (AT) gabi-soft (DOT) fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Display posts from previous:

	C++Talk.NET Forum Index -> C++ Language (Moderated)	All times are GMT Goto page 1, 2 Next
Page 1 of 2

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum