Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk