Merge lp://staging/~gpr/dcplusplus/sync into lp://staging/dcplusplus

I'm not quite sure I understand why one of the counters uses interprocess::detail and the other shared_ptr::detail - if we're relying on internals, I'd minimise their use.

Also, I do not understand the comment on weak vs strong ordering, could you elaborate please.

Regarding fastcriticalsection, it's a spin lock which is quite appropriate if the sections locked are (very) short (small risk of contention) as OS mutexes add a lot of overhead...

About weak/strong ordering, much information is available in internet, for example:
http://en.wikipedia.org/wiki/Memory_ordering
http://en.wikipedia.org/wiki/Memory_barrier
http://msdn.microsoft.com/en-us/library/ms686355(VS.85).aspx

In short, "strong" ordering garantees that all threads in all processors see identical synchronized view of memory, because synchronization primitives (mutex in case of FastCriticalSection in Atomic<strong>) do all necessary memory barriers (synchronization of memory between all processors).

In "weak" ordering (which is used for thread-safe counters in my code), you cannot do any action, based on counter's value. For example, you cannot write code like "if (counter==0) do_some_multithread_action()" because only counter value is synchronized (during atomic access to it), and other memory content may be stale. This is suitable for accounting of some statistics for example.

For smart pointer counters, it is necessary to synchronize memory only in case when counter reaches zero, when destructor is called. This is exactly what shared_ptr counters do. So I used shared_ptr/atomic for intrusive_ptr refcount, which was designed exactly for this purpose - thread-safe refcounting in smart pointers.

But shared_ptr/atomic does not have assignment semantics, only construction. So for Atomic<weak> I used another atomic from boost - interprocess::detail. My Atomic template was designed to be general-purpose thread-safe counter, so it should have assignment.

My motivation for writing all this patches (besides bug in using pthread_cond) was bad (coarse) locking for unix. It uses one static mutex in Thread class for almost all synchronization in the whole code.

While I agree that spinning is suitable for FastCriticalSection, it's not easy to implement it properly and effective. At first glance, current implementation may be subject to priority inversion, and therefore, deadlocks.

I'm not sure, what solution will be acceptable for both unix and windows. For intrusive_ptr, I'd just use boost shared_ptr/atomic (as in my patch). For critical sections, I think correctness is priority, and then optimization. And portability is also good.