incubator-stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Liviu Nicoara <>
Subject Re: STDCXX-1056 [was: Re: STDCXX forks]
Date Tue, 18 Sep 2012 22:42:06 GMT
On 09/18/12 18:24, Stefan Teleman wrote:
> On Tue, Sep 18, 2012 at 4:35 PM, Liviu Nicoara <> wrote:
>> I will concede that I might be wrong and I am open to arguments. I would
>> accept as a counter-argument this program if you can show a runtime failure.
> The the first read of the counter variable is outside a mutex lock
> correct? The read is followed by a 0 comparison, correct?


> What guarantees that between the read and the comparison the value of
> the counter variable hasn't been modified by another thread? The
> thread currently doing the comparison cannot guarantee it: it hasn't
> locked the mutex. Other threads may be running - actually they
> probably are. Another thread may have already acquired the mutex and
> incremented the value of counter. Your thread has no way of knowing if
> that has happened, because it does not yet have exclusive access to
> the counter variable. It will, after it acquires the mutex.

It does not matter if the value is changed concurrently in between the 
reading of it and the actual comparison. The value can only be 0, in 
which case it takes the branch that locks the mutex and the next read 
will absolutely see a fresh value; or it can be 1 in which case it has 
already been initialized and this thread does not pay the penalty of a 
lock anymore.

> Where is it reading the variable  from? A register? Is it declared
> volatile? L2 cache? L3 cache?

Irrelevant. If the value has not been changed it can be read from either 
the cache or directly from the memory. If the value has been changed 
concurrently in between the reading and the actual comparison, the 
processor sees either a stale value of 0, or the new value 1. It is 
guaranteed that any thread reading the value after the (one and only) 
unlock will see a fresh value.

> The program, as you wrote it, implicitly acknowledges that it is not
> thread safe. That is the point of the double check: one before the
> mutex lock, and one after it.

That is a misstatement of the program intentions. See below.

> The point of the first check has nothing
> to do with thread-safety, and everything to do with a minor
> optimization: if the value stored in variable counter is already not
> zero, then there's no point in locking the mutex or performing the
> increment.

The first check is indeed an optimization. It is the point of this 
exercise to show that the unguarded reads in the localization library 
are not defects and the code, simplified in my test case, is thread safe 
in exactly the respects I mentioned before: the program only observes 
consistent, correct values (program states) in a concurrent environment.



View raw message