From: Simon Thornington (simon.thornington_at_[hidden])
Date: 2008-08-22 02:44:21
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
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.
2008/8/21 Peter Dimov <pdimov_at_[hidden]>
> 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
>> all, it's strictly a compiler optimization barrier. I was wondering if
>> someone had any documentation to contradict this, or if boost is relying
>> 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
>> am not sure that's the case. I'm not an expert though.
> What specific _ReadWriteBarrier use do you find suspicious?
> Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk