Subj : Re: Memory visibility and the C compiler... ( a bit long )
To   : comp.programming.threads
From : SenderX
Date : Sat Jan 15 2005 04:36 am

>     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?


> For most compilers this is not too
> difficult: the things that happen in pthread_mutex_lock(),
> say, are modelled well by C's notions of side-effects and
> sequence points.  Since the compiler doesn't usually "know"
> what global data an external function might read or write,
> it won't take the risk of reordering accesses to those data
> across function calls.

That's what I assumed when I was drafting my paper.


>     When you're trying to roll your own synchronization with
> something like sequences of asm() code inserted inline amid the
> C code, you need to know how to prevent the compiler from being
> too aggressive.

My library uses externally assembled routines for basically everything that
requires precise ordering: stacks, queues, eventcounts's, ect.... So, an
aggressive "link-time" optimizer still might be able to mess things up?

If so, luckily! , "most" of the lock-free stuff I have does not require the
user to make multiple functions calls to implement their functionality. For
instance, a "single call" to an external routine is made to pop a node from
a lock-free stack. All of the lock-free garbage collection is also contained
in this single external routine. I figured, since it "does not" take
multiple calls to pop a node from a lock-free stack, the compiler has no
chance to reorder anything?


> For compiler X you may simply "know" that asm()
> code never gets rearranged; for compiler Y you may need to
> utter the magic _Pragma to prevent the rearrangement.  This is
> one of the reasons it's difficult to rebuild your kernel with
> a different C compiler ...

I see.

.