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

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
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_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
>> 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
>