Subj : Re: Can C++ local static objects be made thread safe?
To   : comp.programming.threads,comp.std.c
From : Douglas A. Gwyn
Date : Fri Feb 18 2005 09:55 am

Mime-Version: 1.0
Date: Fri, 18 Feb 2005 17:32:25 GMT
X-Mailer: Mozilla 4.79 [en] (X11; U; SunOS 5.8 sun4u)
Xref: newsmst01a.news.prodigy.com comp.programming.threads:48852 comp.std.c:66591

David Hopwood wrote:
> David Schwartz wrote:
> > "Alexander Terekhov" <terekhov@web.de> wrote...
> >>Under C/POSIX different objects just can't have the same address.
> >>And threads share the entire address space. By definition.
> >     That's ridiculous. Providing no strictly-conforming code can tell the
> > difference, POSIX is silent.
> I keep hearing this idea that POSIX (or Standard C) only imposes
> requirements for strictly-conforming code. Where does it come from?

All such standards have an "escape clause" to the effect
that if your program does not follow certain specified
rules, its behavior is no longer guaranteed by the standard.

The category of "strictly conforming program" means for C
several things, essentially that the output of the program
does not depend on any unspecified ir implementation-defined
properties and does not invoke undefined behavior.  Since
the C host model does not include platform-specific interfaces,
in particular that means that no POSIX-specific functions can
be used.  The purpose of strict conformance can be seen in the
requirement that *every* conforming C implementation "accept"
every s.c. program.  (Whether the program will "work" depends
on whether it exceeds resource limits.)  Thus, a s.c. program
is in a specific sense "maximally portable" across different
platforms.

POSIX conformance is somewhat different, but amounts to an
extension of the Standard C environment to include support
for the headers, functions, etc. specified by POSIX.  The
POSIX *thread* specification adds yet another set of functions
and rules for their use.

> This is quite relevant to c.p.threads, BTW. Not imposing any requirements
> for code that has nondeterministic, i.e. unspecified, behaviour would make
> POSIX useless for multithreaded programming.

POSIX certainly requires that Standard C rules apply within
a single thread.  Because a POSIX thread is created within a
particular function invocation, the only way threads can
validly share data is via globals (extern data) or pointers.
There was a lot of dispute in a thread a few months ago about
whether volatile qualification is necessary for accesses to
shared objects.  My reading of the POSIX thread spec says yes,
others say no.  In any case, you'd better interlock such
accesses using the functions POSIX provides for that purpose.
(The specific argument was whether such interlock functions
also flushed any cached values.  I find it hard to believe
that that could be the intent, since it's not obvious that
such a requirement could be met on many reasonable platforms.)

.