Re: [boost] _ReadWriteBarrier as memory fence, or not?

From: Peter Dimov (pdimov_at_[hidden])
Date: 2008-08-22 10:58:39

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. :-)