Subj : Re: double-checked locking in C To : comp.programming.threads From : Laurent Deniau Date : Wed Jul 06 2005 03:00 pm Joe Seigh wrote: > Laurent Deniau wrote: > >> Joe Seigh wrote: >> >>> 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. > > > Most people don't realize that it's not just reads that can be out of > order but writes as well. So you need release semantics on the store > of the init flag as well as acquire semantics on the load of that flag. This is done by the mutext lock and unlock. They unsure synchronization of the memory content with other threads (otherwise mutex would be completely useless). I do not have to deal with such problem (and it is not possible at the level of C). > There was nothing in your example showing that the initialization stores > had to appear in memory before the store to the init flag did. This is the problem of unlock, not mine. Between the lock/unlock I *only* must ensure that if other threads see a value in the first test (by a premature memory commit), it is a valid value, which by the way never change after being set. The rest is done by lock/unlock. Remember the context: C language, singleton pattern (or unique initialization) and DCL. Nothing more. If you still see a problem in my code, please show me a sequence of actions (sequence points) done by two (or more) threads which breaks the semantic of the singleton pattern. ld. .