Subj : Re: double-checked locking in C
To   : comp.programming.threads
From : David Schwartz
Date : Wed Jul 06 2005 11:13 am


"Laurent Deniau" <Laurent.Deniau@cern.ch> wrote in message 
news:dagijn$1p6$1@sunnews.cern.ch...

> David Schwartz wrote:

>>     Err, what?! If it's not guaranteed to work by the relevent standard, 
>> it's not portable.

> You mean that calling a function between the pair lock/unlock is not 
> portable? Which standard?

    No, I mean writing data in one thread and then reading it another thread 
when the second thread does not hold the same lock the first thread held 
when it wrote the data is not portable. As for which standard, no standard. 
That's my point. No standard guarntees the second thread will see the 
correct value.

>>     Why can't the assignment be delayed until after the unlock?
>
> In principle it could if unlock does not need to synchronize its CPU 
> cache, but in that case it has no effect on the semantic of the code 
> above.

    It destroys the semantics of the code above because another thread might 
see the initialized variable set to true but get the wrong values for 
anything initialized.

>> And what guarantees that a CPU that never acquired the mutex sees the 
>> initialization itself?

> I do not understand your point. If it does not acquire the mutex, it means 
> that it has seen a valid value for initialized. So I do not see a problem. 
> Could you give a sequence underlining the problem ?

    See my other post. The problem is that nothing guarantees that a thread 
that thinks the initialization has completed actually sees the 
initialization.

    DS

.