Subj : Re: double-checked locking in C
To   : comp.programming.threads
From : Laurent Deniau
Date : Wed Jul 06 2005 01:37 pm

Joe Seigh wrote:
> Laurent Deniau wrote:
> 
>>
>>
>> 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.
>>
>> void function(void)
>> {
>>     if (!initialized) {
>>        pthread_mutex_lock(&mutex);
>>        if (!initialized)
>>           initialized = extern_init_code();
>>        pthread_mutex_unlock(&mutex);
>>     }
>> }
>>
>> The compiler is not allowed to assign initialized *before* 
>> extern_init_code() returns. The processor will not be able to do the 
>> same since this is a true jump with a return value. The assignment 
>> could be delayed but not after the unlock, so it is not a problem.
>>
> No.  While most processors have dependency orderings, not all do.  And
> they're usually not part of the processor's formal memory model so you
> have to be extra careful.  And the dependency stuff doesn't provide
> release semantics which is usually where people mess up here, your
> example for instance.

I do not undertstand your point. How a processor can assign a value that 
it does not know yet? If you refer to the small assembly code as a 
proof, I think you are confusing object allocation and object 
construction. singletons[i].reference is assigned *after* object is 
allocated (value returned by allocator function) and *before* object is 
constructed, which is a different point.

> http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html

I don't see anything in this paper showing a problem with what I say. 
Could you point me the place?

a+, ld.

.