Re: [boost] lightweight_once

From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2007-09-03 05:44:17

Peter Dimov wrote:
> Tobias Schwinger:
> 
>> Most processors have linear write buffers and if 'initialized' is seen
>> as true the object has been written, too.
> 
> The write buffer in thread 1 doesn't affect the reads in thread 2, which can 
> still be reordered.
> 
> True if by "most processors" you mean "x86", though, absent compiler 
> optimizations.

Well, the article I referenced states that in the particular case we 
have been discussing one can get away without a second read barrier for 
PPC as well.

AFAIK (not claiming to be an expert in this field, however) reordering 
of this kind (that is, crossing branches) is unlikely to happen with 
most processor architectures (seems it would take redundant pipelines 
executing both alternatives of a branch - probably an obsolete concept 
given effective branch prediction).

> Hasn't Anthony Williams already implemented a header-only call_once? I'm not 
> sure I see a reason to reinvent that particular wheel. Once boost::mutex is 
> made header-only, there'd be no need for lightweight_mutex either and I'll 
> be able to retire it as well. 

Interesting. I very much like the clean-looking code and using a named 
mutex seems better to me than calling 'Sleep(1)' in a loop for Windows.

But again, concurrent calls to 'call_once' block each other. It might 
make sense to add another variant that (possible comes at a higher cost 
and) does not have this limitation...

The pthread-based implementation seems overly simplified: It won't 
compile for C++ functions that are not 'extern "C"' with some compilers. 
Further, what about exceptions from within pthread_once?

The coverage of the test-suite seems a bit thin: No recursive 
application of 'once', no tests with exceptions being thrown, ...

All in all, it's a step forward but not mature enough to call it "wheel" 
that is reinvented by an alternative implementation ;-).

Regards,
Tobias