Subj : Re: posix and lock-free algorithms
To   : comp.programming.threads
From : Mayan Moudgill
Date : Fri Aug 12 2005 08:01 pm

Sean Kelly wrote:
> Joe Seigh wrote:
> 
>>Sean Kelly wrote:
>>
>>>Exactly.  To make this point easier to understand, I suggest applying
>>>it to a clustered system--each machine might implement synchronization
>>>via message-passing.  In such an environment, it's obviously far more
>>>efficient to only synchronize data altered within the critical section.
>>>
>>
>>Locks don't just synchronize data altered within the critical section.
>>They have release semantics for data altered before releasing the lock and
>>acquire semantics for data accessed after acquiring the lock.  A lot of
>>stuff would break otherwise.
> 
> 
> True enough.  But does this matter so far as the POSIX spec is
> concerned?  ie. I may know that this will work:
> 
> int i, j;
> 
> void* thread1(void*) {
>     j = 1;
>     // acquire mutex M
>     i = 2;
>     // release mutex M
> }
> 
> void* thread2(void*) {
>     // acquire mutex M
>     if( i == 2 ) assert( j == 1 );
>     // release mutex M
> }
> 
> ie. the store for j must occur before the release of M in thread1.  But
> the spec says nothing about this, correct?
> 
> 
> Sean

Actually, it is worse than this. As declared, an ISO standard compliant 
C compiler is free to reorder, get rid of, and do miscellaneous other 
optimizations to i and j. ISO/ANSI C has *NO* knowledge of 
multi-threading or concurrent execution. There are only a couple of 
requirements  that the compiler has to satisfy:
- the optimized code must have the same black-box behavior as the 
abstract *sequential* machine
- volatiles force order w.r.t. other volatiles.

Unless you declare i & j as volatile, all bets are off. And all the talk 
about POSIX (in the context of C) is meaningless, since you're trying to 
impose a requirement on the code that is not expressible in the 
underlying language (well, at least not in C)

.