Subj : Re: double-checked locking in C
To   : comp.programming.threads
From : Laurent Deniau
Date : Thu Jul 07 2005 11:48 am

David Schwartz wrote:
> "Laurent Deniau" <Laurent.Deniau@cern.ch> wrote in message 
> news:42CC493F.4020705@cern.ch...
> 
> 
>>Now, there is the problem of reflecting the change of the side effects to 
>>other threads. My suggestion was to put the flag inside the side object 
>>itself. Therefore if the init_value is seen, the object is also seen. Of 
>>course you may think that the object takes place on cache line boundary 
>>and is only partially updated. That is in the worst case, only the flag 
>>part and not the rest. But I am not sure if this can happen.
> 
> 
>     You just don't get it. We're talking about *PORTABLE* code written for 
> an abstract machine. There is no such thing as a cache line.

Right, I was try to examine how it could fail.

>     You have the guarantees the standards give you. And that's it. If you 
> claim anything else is guaranteed, then you have code that's *not* portable.

Then if I stick to standards, the C norm is enough (6.7.3-6 which says 
all and nothing) and I just have to use volatile. At the sequence 
points, the value is correct even if modified by side effects. But as 
you know, it doesn't solve anything because of the presence of caches on 
processors, something absent from the norm and very uncommon at the time 
volatile was invented.

>     You said:
> 
>>There is a simple, portable, processor independent, compiler independent 
>>idiom which consists of delegating the work to an extern function, a 
>>function with an implementation in a different translation unit.

Yes. The point in the discussion was to garantee the assignment after 
the init_code is executed. As I have shown, managing the side effects is 
another problem since you may not have side effects in init_code.

But I have failed is to find a solution for the singleton pattern. I 
agree, the code I proposed is not portable.

So it seems that there is no way to make it efficient. An intermediate 
solution would be to use pthread_once. It is faster than lock (at least 
on my OS) but much slower than DCL.

ld.

.