Subj : Re: YALFAm (Yet Another Lock Free Approach, maybe)
To   : comp.programming.threads
From : Chris Thomasson
Date : Fri May 27 2005 02:19 pm

>
> Humm, I wonder if that would be good enough explanation of guaranteed 
> behavior wrt memory visibility/compiler-safety for acquire/release 
> semantics...

I wonder if this would also be sufficent:


Generic Mutex Implementation
 - Memory Visibility Guarantees
--------------------

A thread of execution in a multi/uni-processor environment will always 
observe the following states during the entire (lock=>unlock) state 
transformation inherit in any mutex, in the exact order shown:

lock   c-section   unlock
---------------------------

1    =>    2    =>   3


State 2 can never be observed before state 1, and state 3 can never be 
observed before states 2 or 1. The "=>" symbol represents a state transition 
point. Effects of any prior states are required to be fully visible to any 
new states.


Humm, these rules seem to imply explicit acquire/release semantics 
naturally. The transition from (1=>2) requires acquire in order to make 1 
become visible before 2, and the transition from (2=>3) requires release in 
order to make 2 become visible before 3. Any thoughts on using state 
transition flowcharts for memory visibility documentation?

.