From: Peter Dimov (pdimov_at_[hidden])
Date: 2006-07-02 15:42:07
Sean Parent wrote:
> ONCE <http://opensource.adobe.com/group__adobe__once.html>
> The STATIC_INSTANCE stuff might be able to be removed - this was
> done for the Mac where static initializer on DLLs were getting
> executed on a thread after load so other functions in the compilation
> unit could be executed concurrently. That may have been fixed (I
> haven't tracked the issue) - this library would be a good addition to
> Boost threads.
adobe::call_once should really be folded into boost::call_once, the rest
would require more thought.
> Counter <http://opensource.adobe.com/classadobe_1_1counter__t.html>
> If boost would surface the lightweight mutex used in shared_ptr -
> this would go away. (This is a heavyweight one - as I'm counting on
> Boost providing a lightweight one in the future :-) ).
The closest boost equivalent is boost::detail::atomic_count. We really need
an atomic operations library to isolate the platform-specific functionality
that is currently scattered all over the place...
As for lightweight_mutex, it should ideally be subsumed by boost::mutex;
there is no real reason for boost::mutex to be heavyweight (and in order to
replace lightweight_mutex, it should be header-only because of its "critical
piece of infrastructure" status.)
One subtlety when specifying a counter type such as counter_t is that its
memory synchronization guarantees need to be documented. No msync on
increment, full msync on decrement is probably the simplest option that
supports a reference-counted pointer and doesn't sacrifice performance too
much; a slightly more refined approach is to guarantee acquire semantics on
a decrement with new value zero, release semantics otherwise. Copy on write
requires even less.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk