Opened 11 years ago
Closed 8 years ago
#6782 closed Bugs (fixed)
call_once uses incorrect barrier intrinsic on Visual Studio
Reported by: | Owned by: | viboes | |
---|---|---|---|
Milestone: | Boost 1.57.0 | Component: | thread |
Version: | Boost 1.49.0 | Severity: | Problem |
Keywords: | Cc: |
Description
boost\thread\win32\interlocked_read.hpp uses _ReadWriteBarrier() as a barrier. However, according to MSDN and the machine code generated, it doesn't emit any memory barrier instructions at all:
The _ReadBarrier, _WriteBarrier, and _ReadWriteBarrier compiler intrinsics prevent only compiler re-ordering. To prevent the CPU from re-ordering read and write operations, use the MemoryBarrier macro.
So one should use the MemoryBarrier() macro instead. In fact according this page _ReadWriteBarrier is not necessary for volatile variables access since VS2005.
Thanks,
- Galka.
Change History (5)
comment:1 by , 10 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:2 by , 10 years ago
wouldn't be enough to remove these lines and let the implementation using boost/detail/interlocked.hpp?
#ifdef BOOST_MSVC extern "C" void _ReadWriteBarrier(void); #pragma intrinsic(_ReadWriteBarrier) namespace boost { namespace detail { inline long interlocked_read_acquire(long volatile* x) BOOST_NOEXCEPT { long const res=*x; _ReadWriteBarrier(); return res; } inline void* interlocked_read_acquire(void* volatile* x) BOOST_NOEXCEPT { void* const res=*x; _ReadWriteBarrier(); return res; } inline void interlocked_write_release(long volatile* x,long value) BOOST_NOEXCEPT { _ReadWriteBarrier(); *x=value; } inline void interlocked_write_release(void* volatile* x,void* value) BOOST_NOEXCEPT { _ReadWriteBarrier(); *x=value; } } } #else #endif
comment:3 by , 8 years ago
I believe Boost requires VS2005 minimum now, so I have removed the ReadWriteBarrier completely as volatile reads always acquire and volatile writes always release. MSVC generates the appropriate acquire-release opcodes on ARM, and on x86 they are unnecessary as all loads acquire and all stores release. This ticket can now be closed. Niall
comment:4 by , 8 years ago
Milestone: | To Be Determined → Boost 1.57.0 |
---|
comment:5 by , 8 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
Could you provide a test that proves the issue. And a patch to solve it?