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. 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. detail_w32.hpp explicitly declares them all BOOST_COMPILER_FENCE which I take to mean the author is not assuming a memory fence. Also, I don't see off-hand any situations in which ordering would matter there given the use of the interlocked primitives. Cheers, Simon. 2008/8/21 Peter Dimov <pdimov@pdimov.com>
Simon Thornington:
Hi folks,
Quick question about the use of _ReadWriteBarrier (Win32 MSVC):
According to http://msdn.microsoft.com/en-us/library/ms684208(VS.85).aspx<http://msdn.microsoft.com/en-us/library/ms684208%28VS.85%29.aspx>, this compiler intrinsic doesn't generate any memory fencing instructions at all, it's strictly a compiler optimization barrier. I was wondering if someone had any documentation to contradict this, or if boost is relying on the new volatile semantics in VC2005 to ensure the fence?
It sure looks like it's being used as if it were a real memory fence, but I am not sure that's the case. I'm not an expert though.
What specific _ReadWriteBarrier use do you find suspicious? _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost