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.