Subj : Re: posix and lock-free algorithms
To   : comp.programming.threads
From : Joe Seigh
Date : Fri Aug 12 2005 05:39 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?
> 

Right, the spec doesn't exactly specify anything but it's part of the de facto
semantics.  E.g. things like synchronized fifo queues would break if
accesses to the objects being queued and dequeued weren't synchronized
as well.


-- 
Joe Seigh

When you get lemons, you make lemonade.
When you get hardware, you make software.

.