Subj : Re: Memory visibility and the C compiler... ( a bit long )
To   : comp.programming.threads
From : Eric Sosman
Date : Wed Jan 19 2005 11:03 am



SenderX wrote:
>>    The compiler is a part of the Pthreads implementation,
>>and must refrain from doing things that would violate the
>>Pthreads semantics.
> 
> 
> Does the compiler actually look for calls to all pthread_xxx sync functions,
> and prevents aggressive optimization of function call/shared&local variable
> ordering across them? Basically, what I'm asking is: How do an aggressive
> compiler and/or link-time optimizer for a "pthread conforming compiler"
> interact with the pthread standard?

    The mechanisms are the province of the provider of the
Pthreads implementation.  The (not very profound) point I'm
trying to make is that the provider cannot just furnish a
library of functions and a few headers, but also a compiler
(and linker, and loader, and kernel, and ...) that works with
the other pieces to satisfy the Pthreads specification.

    You can't expect a "Pthreads library" to work correctly
with every J. Random Compiler than happens to waltz along.
This is because some of the Pthreads semantics cannot be
expressed in C, so you have (for example) no portable way to
tell the compiler of the relationship between mutex X and
protected data structure Y.  As a Pthreads provider, you must
rely on non-portable knowledge about the compiler ("I happen
to know that this compiler never rearranges data accesses
across calls to external functions").  If the compiler *is*
capable of such rearrangments (or of other optimizations that
would mess up the required semantics), you need to use extra-
linguistic constructs like "#pragma strict_sequence" to tell
it not to do so with particular functions.  And, of course,
neither the a priori knowledge nor the necessary incantations
are applicable to J. Random Compiler, ...

    That's all I'm saying: The library and headers are just
two of several components that must all work together to make
up a Pthreads implementation.  If you separate one component
from the rest of the suite, that component in isolation is
not a Pthreads implementation, even if it happens to be a
library containing pthread_mutex_lock() and all the rest.

-- 
Eric.Sosman@sun.com

.