thread safety
E. Robert Tisdale
> Richard Edgar wrote
>
>> ... there would have to be a part of the standard
>> which said that in
>>
>> void func(void) {
>> int i;
>>
>> // etc.
>> }
>>
>> the variable I was _never_ statically allocated (since it is not
>
> declared
>
>> static). The OP seems curiously reluctant to point to the specific part
>
> of
>
>> the standard which guarantees this. This makes me wonder if 'normal
>> practice' and 'standard compliant practice' are being confused.
>
>
> I'll do the homework for the OP. In Section 6.1.2.4
> Storage durations of objects in ANSI/ISO 9899-1990:
> <Quote>
> An object whose identifier is declared with no linkage [GC note: extern]
> and without the storage-class specifier static
> has automatic storage duration.
> Storage is guaranteed to be reserved
> for a new instance of such an object
> on each normal entry into the block with which it is associated...
> </Quote>
I have taken the liberty of cross posting to the comp.std.c newsgroup
so that experts on the ANSI/ISO C standards can comment.
The question is whether or not it is possible to write
*portable* thread safe [sub]programs in Fortran 77/90/95/00.
Most modern Fortran compilers use or, at least, can use
automatic storage for local variables unless they are SAVE'd
but this is *not* required by any ANSI/ISO Fortran standard.
Fortran compilers are allowed to reserve static storage
for all local variables which would practically preclude thread safety.
Fortran proponents argue that, since the ANSI/ISO C standards
do *not* explicitly specify thread safety, there is no guarantee that
it is possible to write portable thread safe [sub]programs in C either.
James Kuyper
...
> Fortran proponents argue that, since the ANSI/ISO C standards
> do *not* explicitly specify thread safety, there is no guarantee that
> it is possible to write portable thread safe [sub]programs in C either.
They are correct. The C standard says nothing about threads, period, so
everything connected to them is undefined, unspecified, or
implementation-defined behavior. How could you expect otherwise?
That is, however, an unfair comparison. The C standard isn't the only
one that can apply to a C compiler. It may be possible to write portable
thread-safe [sub]programs, as long as you invoke not just the C
standard, but also some other standard that does describe threaded
behavior, such as POSIX. Such code would only be portable to
implmentations conforming to that other standard, but that's a lot
better than not being portable at all.
Alexander Terekhov
James Kuyper wrote:
[...]
> That is, however, an unfair comparison. The C standard isn't the only
> one that can apply to a C compiler. It may be possible to write portable
> thread-safe [sub]programs, as long as you invoke not just the C
> standard, but also some other standard that does describe threaded
> behavior, such as POSIX. Such code would only be portable to
> implmentations conforming to that other standard, but that's a lot
> better than not being portable at all.
http://groups.google.com/groups?threadm=3EB82EA0.F40E66C4%40web.de
(Subject: __attribute__((cleanup(function)) versus try/finally)
http://lists.boost.org/MailArchives/boost/msg47747.php
http://groups.google.com/groups?threadm=3ECFA41C.A3B7A957%40web.de
(Subject: Upcoming ISO/IEC <thread>... and <pthread.h> -> ... )
regards,
alexander.
Larry Jones
>
> The question is whether or not it is possible to write
> *portable* thread safe [sub]programs in Fortran 77/90/95/00.
And what does that have to do with the C standard?
> Fortran proponents argue that, since the ANSI/ISO C standards
> do *not* explicitly specify thread safety, there is no guarantee that
> it is possible to write portable thread safe [sub]programs in C either.
It is true that the C standard does not guarantee thread safety, but
that doesn't mean that it's not possible to write portable thread-safe
code in C. It just means that you have to resort to additional
standards, like Posix.
-Larry Jones
Any game without push-ups, hits, burns or noogies is a sissy game. -- Calvin
E. Robert Tisdale
> E. Robert Tisdale wrote:
>
>>The question is whether or not it is possible to write
>>*portable* thread safe [sub]programs in Fortran 77/90/95/00.
>
> And what does that have to do with the C standard?
>
>>Fortran proponents argue that, since the ANSI/ISO C standards
>>do *not* explicitly specify thread safety, there is no guarantee that
>>it is possible to write portable thread safe [sub]programs in C either.
>
> It is true that the C standard does not guarantee thread safety,
> but that doesn't mean that it's not possible
> to write portable thread-safe code in C.
> It just means that
> you have to resort to additional standards, like Posix.
Apparently, the argument is that it is *not* possible
to write portable thread-safe code in Fortran
even if you resort to additional standards, like Posix.
A distinction has been made between *thread safe code*
and code that is actually used in a multithreaded application
which means, I suppose, that the portable thread safe code
need not actually reference any pthread library functions.
Please note that there does not appear to be any consensus
on this yet among subscribers to the comp.lang.fortran newsgroup.
Barry Margolin
>to write portable thread-safe code in Fortran
>even if you resort to additional standards, like Posix.
>A distinction has been made between *thread safe code*
>and code that is actually used in a multithreaded application
>which means, I suppose, that the portable thread safe code
>need not actually reference any pthread library functions.
I believe standards like POSIX place additional restrictions on C
implementations that must be used with them, for instance that automatic
variables must be allocated in thread-local storage. I think POSIX also
requires the user to "warn" that the code could be used in multithreaded
applications, by using -DPTHREAD (or something like that) when compiling;
this allows the implementation to link in the right library functions and
use thead-safe macros (if the implementation is inherently safe then it can
simply ignore the warning).
Presumably POSIX bindings for other languages, like Fortran, should have
similar constraints on their implementations.
--
Barry Margolin, barry.m...@level3.com
Level(3), Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Brooks Moses
> E. Robert Tisdale <E.Robert...@jpl.nasa.gov> wrote:
>>The question is whether or not it is possible to write
>>*portable* thread safe [sub]programs in Fortran 77/90/95/00.
>
> And what does that have to do with the C standard?
Nothing, directly. There has been debate about the answer, however, and
in particular about the part of the answer that claims that using C
instead (which Robert was proposing to do if he couldn't write portable
thread-safe code in Fortran) is a better solution -- and so, whether he
uses C or Fortran, he can't expect to be able to write portable code
that _any_ standard-conforming compiler will compile in a thread-safe
manner. (And so, since he has to deal with that anyhow, he might as
well deal with it and use Fortran as he prefers to.)
>>Fortran proponents argue that, since the ANSI/ISO C standards
>>do *not* explicitly specify thread safety, there is no guarantee that
>>it is possible to write portable thread safe [sub]programs in C either.
>
> It is true that the C standard does not guarantee thread safety, but
> that doesn't mean that it's not possible to write portable thread-safe
> code in C. It just means that you have to resort to additional
> standards, like Posix.
Hmm. I guess, at this point, the debate should probably move into a
question of how well-supported the various applicable additional
standards are. It was, at one point, mentioned that there are
additional standards for Fortran (e.g., HPF) that specifically provide
for thread support.
The question also probably arises as to whether or not various Fortran
compilers support the relevant parts of the Posix standards, granted
that (in this case) the code is expected to be linked to modules written
in C.
- Brooks
Dan Nagle
On Thu, 12 Jun 2003 12:17:51 -0700, "E. Robert Tisdale"
<E.Robert...@jpl.nasa.gov> wrote:
<snip requoted>
>
>I have taken the liberty of cross posting to the comp.std.c newsgroup
>so that experts on the ANSI/ISO C standards can comment.
I've read (at least some of) the replies from comp.std.c,
I'd like to thank those posters for their helpful comments.
This thread is now upwards of 80 posts in c.l.f :-)
I'll try to briefly summarize it so readers in c.s.c need
not read through its entirety. I hope I can do so fairly,
I do have several posts in this thread myself.
>
>The question is whether or not it is possible to write
>*portable* thread safe [sub]programs in Fortran 77/90/95/00.
And the answer which has been given (repeatedly, in different forms,
:-) by several c.l.f regulars) is that most Fortran compilers
supporting computers which allow multithreading have some means
of producing thread safe objects.
In many instances, this will require a compiler option to request
that thread safe code be generated. This situation has been
compared as roughly similar to the situation in C, where
a compiler switch *may* be needed for thread safety.
In C and in Fortran, the program must restrict itself
to a subset of the entire language, and typically at least,
must set a compiler option to "guarantee" a thread safe object.
That is, thread safety is more than storage mechanism
of local variables.
>Most modern Fortran compilers use or, at least, can use
>automatic storage for local variables unless they are SAVE'd
>but this is *not* required by any ANSI/ISO Fortran standard.
A confusion which has appeared in this discussion is
that "automatic storage local variables" is equivalent
to "thread safe objects". A compiler *may*, for example,
use static storage for local variables if it reserves enough
static storage for some anticipated maximum number of threads,
or the program allocates storage for a number determined
during execution. This may be done either by the compiler
or explicitly by the programmer. The same general techniques
may be used either in Fortran or in C. And a compiler option
will surely be needed.
>Fortran compilers are allowed to reserve static storage
>for all local variables which would practically preclude thread safety.
This sort of statement appears to me to be confusing storage
mechanism, on the one hand, with (thread v. process) scope
of variable, on the other. In some posts, the OP (E. Robert Tisdale)
has added the qualifier "without using a mutex" which furthers my
suspicion that he is confusing the storage mechanism of a variable
with the scope of a variable. Of course, if one has a process scope
variable where a thread scope variable is needed, use of a mutex
will simply atomically overwrite the variable. This is
a correctness issue, not a performance issue. The OP has implied
this is a performance issue (it would be a performance issue,
if one had a correct program!).
>Fortran proponents argue that, since the ANSI/ISO C standards
>do *not* explicitly specify thread safety, there is no guarantee that
>it is possible to write portable thread safe [sub]programs in C either.
The second paragraph of C99 5.1.2.3 is becoming notorious. :-)
It is taken as implying that C99 defines single threaded execution.
The conclusion is drawn that multithreaded execution is beyond C99.
Which leads us right back to the "thread safe means more than
storage class" perspective.
At this point, the thread appears to iterate. :-)
In short, the OP appears to be interpreting the Fortran standard
pessimistically and the C standard optimistically, with regards
to producing thread safe objects. Standards beyond C99 and Fortran 95
have not been discussed in the c.l.f thread until today.
Some of the regulars in c.l.f are members of J3, the U.S. Fortran
standards committee, which recently wrote the "Interoperability
with C" section of the in-the-works Fortran 2000 standard.
There is, perhaps, more familiarity with C99 than might be expected
from a typical Fortran programmer. I hope I have understood
C99 accurately. "Interoperability with C" is regarded as one of,
if not the, most important feature(s) of Fortran 2000.
{The latest draft of the Fortran 2000 standard is available
from http://www.j3-fortran.org, click on "Fortran 2000"
with Javascript enabled. It's several MB of PDF.)
--
Cheers!
Dan Nagle
Purple Sage Computing Solutions, Inc.
Francis Glassborow
<dna...@erols.com> writes
>Some of the regulars in c.l.f are members of J3, the U.S. Fortran
>standards committee, which recently wrote the "Interoperability
>with C" section of the in-the-works Fortran 2000 standard.
>There is, perhaps, more familiarity with C99 than might be expected
>from a typical Fortran programmer. I hope I have understood
>C99 accurately. "Interoperability with C" is regarded as one of,
>if not the, most important feature(s) of Fortran 2000.
Then it is long past time that we improved our liaison with Fortran.
--
ACCU Spring Conference 2003 April 2-5
The Conference you should not have missed
ACCU Spring Conference 2004 Late April
Francis Glassborow ACCU
Alexander Terekhov
Dan Nagle wrote:
[...]
> to producing thread safe objects. Standards beyond C99 and Fortran 95
> have not been discussed in the c.l.f thread until today.
Save your time. It's impossible to have portable "thread safe objects"
because POSIX's "memory model" sucks -- it doesn't define what "memory
location" is. OG/AG folks are just waiting until the Std. C/C++ will
finally adopt threads, I guess.
regards,
alexander.
Dan Nagle
Please accept my invitation to attend J3 meetings.
See http://www.j3-fortran.org for time & place
(next: Las Vegas, mid-August) details.
--
Cheers!
Dan Nagle
Purple Sage Computing Solutions, Inc.
Francis Glassborow
<dna...@erols.com> writes
>Hello,
>
>Please accept my invitation to attend J3 meetings.
>See http://www.j3-fortran.org for time & place
>(next: Las Vegas, mid-August) details.
Thanks, but as a self-financed individual attending both WG14 and WG21
meetings is already stretching my finances.
Alexander Terekhov
Francis Glassborow wrote:
[...]
> Thanks, but as a self-financed individual attending both WG14 and WG21
> meetings is already stretching my finances.
That's yet another really good reason why both WG14 and WG21 should
(*ASAP*) follow "the process" initiated by WG15 (self-destruction, I
mean). BTW, OG/AG's confcalls are free (in US and Canada) and have a
local number in the UK, Francis.
regards,
alexander.
--
http://groups.google.com/groups?selm=3D73F24D.442DC71A%40web.de
(Subject: Re: C and C++: Case Studies in Compatibility)
Francis Glassborow
<tere...@web.de> writes
>
>Francis Glassborow wrote:
>[...]
>> Thanks, but as a self-financed individual attending both WG14 and WG21
>> meetings is already stretching my finances.
>
>That's yet another really good reason why both WG14 and WG21 should
>(*ASAP*) follow "the process" initiated by WG15 (self-destruction, I
>mean). BTW, OG/AG's confcalls are free (in US and Canada) and have a
>local number in the UK, Francis.
But most of us know that such things as conference calls are not a
substitute for face-to-face meetings.
In addition there is the issue of the enormous number of unpaid hours
that would be required to understand the issues involved between Fortran
and C. Going to meetings only helps empower you to work and relate to
the work of others, it does not get the work done.
My point of concern is that I do not remember seeing documents from J3
relating to interoperability with C and I think that J3 should have been
sharing them with J11 and by that route with WG14.
Alexander Terekhov
Francis Glassborow wrote:
[...]
> My point of concern is that I do not remember seeing documents from J3
Well, http://tinyurl.com/eazl is "withdrawn", but perhaps it still
might help... oder? (after all, POSIX is "almost C"; threads aside
for a moment ;-) )
regards,
alexander.
James Kuyper
Yes? Cross-references like those are a lot more useful if you indicate
how you think they connect to the current discussion.
There was a lot of stuff in there about the C++ standard, and how it's
exception-throwing model works (or fails to) with POSIX. This is
comp.std.c (and comp.std.fortran), and the question was about the C
standard.
One comment caught my attention, though it's not relevant to this
discussion:
"C and C++ WILL merge, sooner or later. The separation of C and C++
languages is/was the stupidest thing C++ authors ever did (or allowed to
happen)."
C is a different language than C++ because some people wanted to
continue using a C which was NOT C++. There's no point in debating
whether they were correct; the relevant fact is that they existed, and
still exist, and comp.std.c is filled with such people. I would point
out that this doesn't mean that they are all haters of C++, many of them
merely feel that C is a better language to use in certain context, not
that C is superior to C++ in all contexts.
Keeping the two languages seperate was not a decision the C++ authors
made, and it's not one that they had any power to prevent from being
made. You could hold them to blame, I suppose, for failing to convice
all of the C holdouts, but that hardly seems fair. That's not quite
true: if they had defined C++ as a language that was nearly identical to
C90, with a few minor changes, then those changes could have been
incorporated into C99. But somehow I doubt that this is what you were
referring to; that wouldn't really have been C++ in any meaningful
sense.
James Kuyper
> Hello,
>
> On Thu, 12 Jun 2003 12:17:51 -0700, "E. Robert Tisdale"
> <E.Robert...@jpl.nasa.gov> wrote:
> >Fortran proponents argue that, since the ANSI/ISO C standards
> >do *not* explicitly specify thread safety, there is no guarantee that
> >it is possible to write portable thread safe [sub]programs in C either.
>
> The second paragraph of C99 5.1.2.3 is becoming notorious. :-)
> It is taken as implying that C99 defines single threaded execution.
> The conclusion is drawn that multithreaded execution is beyond C99.
> Which leads us right back to the "thread safe means more than
> storage class" perspective.
It describes an execution environment in which the possibility of
multiple threads has not even been considered, which means that in
some ways it implicitly assumes single-threaded behavior. Therefore, a
conforming implementation of C on a platform which supports multiple
threads, can compile a strictly conforming program to make use of
multiple threads, only by invoking the "as-if" rule. That means,
basically, that the observable results of the multi-threaded behavior
must be essentially the same as if 5.1.2.3 had been followed literally
for some permitted order of evaluation of the statements and
expressions that make up the program. This provides only a very
limited amount of freedom for multi-threaded implementation of the
program. It's not enough to be really useful, in itself.
However, any program that makes real use of threads will have behavior
that is undefined behavior under the C standard. That's because the
thread primitives are necessarily written in non-strictly conforming
C, because strictly-conforming C doesn't have the features neede to
implement those primitives. Therefore, any program that uses them has
behavior that is at best, implementation-defined, as far as the C
standard is concerned. In most cases, it has undefined behavior. That
gives the implementation all the freedom it needs to make those
threading primitives do whatever it needs them to do. If they conform
to some other standard, such as POSIX, then the behavior becomes
defined; but not by the C standard.
Alexander Terekhov
James Kuyper wrote:
[...]
> There was a lot of stuff in there about the C++ standard, and how it's
> exception-throwing model works
http://groups.google.com/groups?selm=3D95F01E.F4AEB7CE%40web.de
(Subject: Re: C and C++ compatibility - is there a shortcut? Partly to
Mr. Stroustrup)
> (or fails to) with POSIX. This is
> comp.std.c (and comp.std.fortran),
This is now comp.std C without Fortran.
> and the question was about the C
> standard.
Hardly.
>
> One comment caught my attention, though it's not relevant to this
> discussion:
>
> "C and C++ WILL merge, sooner or later. The separation of C and C++
> languages is/was the stupidest thing C++ authors ever did (or allowed to
> happen)."
>
> C is a different language than C++ because some people wanted to
> continue using a C which was NOT C++.
NIH. I know.
regards,
alexander.
Francis Glassborow
<tere...@web.de> writes
>> C is a different language than C++ because some people wanted to
>> continue using a C which was NOT C++.
>
>NIH. I know.
I disagree. And interestingly C99 has triggered a desire from a number
of serious and completely professional programmers to make C90 + the TRs
that applied to it a distinct standard that remains in permanent
maintenance mode (that way existing legacy code cannot be broken by
language change.
I think that a similar argument could be applied to C++. Spin off C++
with metaprogramming support (not just abuse of template technology) as
the next generation member of the C family of languages.
Chris Hills
<francis.g...@ntlworld.com> writes
>In message <3EEB8E91...@web.de>, Alexander Terekhov
><tere...@web.de> writes
>>> C is a different language than C++ because some people wanted to
>>> continue using a C which was NOT C++.
>>
>>NIH. I know.
>
>I disagree. And interestingly C99 has triggered a desire from a number
>of serious and completely professional programmers to make C90 + the TRs
>that applied to it a distinct standard that remains in permanent
>maintenance mode (that way existing legacy code cannot be broken by
>language change.
This is precisely why I got BSI to make C90 available again. They are
good a good trade on a supposedly obsolete standard :-)
One of the main areas for the use of C is the embedded/realtime area
(which is often safety critical) they still use C90 and most (if not
all) the serious tools and industry standards still refer to C90.
It should be noted that many in embedded/realtime area use EC++ and not
C++. The point being is that if ISO C and ISO C++ are merged much of
the "real world" will continue to use C90 and EC++ much like the
majority use VB and ISO Basic is now obsolete.
The standards bodies do need to keep one eye on industry lest we become
irrelevant. NB "one eye" because industry does not hold all the answers
either.
regards
Chris
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\
/\/\/ ch...@phaedsys.org www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/