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.
About weak/strong ordering, much information is available in internet, for example: en.wikipedia. org/wiki/ Memory_ ordering en.wikipedia. org/wiki/ Memory_ barrier msdn.microsoft. com/en- us/library/ ms686355( VS.85). aspx
http://
http://
http://
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.