Simon Thornington:
thread\win32\interlocked_read.hpp bothers me because I don't believe x86 guarantees ordering of loads mixed with stores, but interlocked_read_acquire to my reading implies no upward migration of loads (hardware reordering). I don't believe _ReadWriteBarrier() helps at all in this case.
x86 allows a store to be reordered with a following load. An acquire read should prevent following operations to be reordered with the read, but there is no problem with a preceding operation being reordered.
asio\detail\indirect_handler_queue.hpp bothers me because on non-MSVC platforms, it's using _GLIBCXX_WRITE_MEM_BARRIER which is a real memory barrier. The code might be fine (I'm sure I'm not qualified to comment on it), but the fact that one is a real memory barrier and one is not tweaks me.
This is the most suspicious example but it only needs to prevent the two stores following the barrier from being reordered with the preceding instructions, and on x86 stores never migrate upwards.
detail_w32.hpp explicitly declares them all BOOST_COMPILER_FENCE which I take to mean the author is not assuming a memory fence.
Indeed. :-)