Subj : Re: Formal Mutex Semantics
To   : comp.programming.threads
From : Maciej Sobczak
Date : Tue Aug 16 2005 03:06 pm

Joe Seigh wrote:

> Here's some stuff I was doing a while back on defining thread 
> semantics.
[...]

I cannot find it stated explictly, so here's my request for clarification:

Let's suppose there are two shared mutexes (m1, m2) and two shared 
variables (a, b) initialized to 0.
One thread does this:

lock(m1);      // you can remove this line
a = 1;
unlock(m1);    // you can remove this line
lock(m2);
b = 1;
unlock(m2);

and another thread does this:

lock(m2);
if (b == 1) assert(a == 1);
unlock(m2);

Question is: does your "mutex semantics" guarantee the assertion above?
In other words: is the visibility of stores guaranteed for all stores 
that happened before unlock(m2) in thread 1, even if those stores where 
performed before lock(m2)?

I think such guarantee is not needed and the more relaxed version would 
guarantee that the visibility of stores is guaranteed only for those 
stores that were done when the given mutex was locked. Locking different 
mutex (or not locking it at all - if you remove respective lines above) 
would not guarantee anything with respect to the other thread. It is 
like having stores which are associated only with a given mutex (some 
interesting issues may arise when many mutexes are locked at the same 
time), or putting it in other words, having *selective* flush/refresh 
with the mutex object used as a key for selection.

What was your intention with regard to the example above?

Related question: what does POSIX guarantee for this example?


-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

.