stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Teleman <>
Subject Re: STDCXX-1056 [was: Re: STDCXX forks]
Date Tue, 18 Sep 2012 22:24:26 GMT
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.

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

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. 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


Stefan Teleman
KDE e.V.

View raw message