Boost logo

Boost :

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<>,
>> 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:

Boost list run by bdawes at, gregod at, cpdaniel at, john at