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?