Subject: Re: [Boost-bugs] [Boost C++ Libraries] #8730: Race condition in once_block.hpp
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2013-06-25 19:03:30
#8730: Race condition in once_block.hpp
-------------------------------+------------------------------------------
Reporter: apolukhin | Owner: andysem
Type: Bugs | Status: new
Milestone: To Be Determined | Component: log
Version: Boost 1.54.0 | Severity: Problem
Resolution: | Keywords: call_once atomics thread log
-------------------------------+------------------------------------------
Comment (by apolukhin):
Replying to [comment:1 andysem]:
> Which implementation are you referring to?
>
> > First of all, once_block_flag is not thread safe.
>
> What makes you think so? It is POD, and all its modifications in the
library are made in a thread-safe way (given that you use the multi-
threaded build of the library).
POD *does not* guarantee atomicity. Take a look at Boost.Atomic library
and note that even bools and integers are wrapped around in classes and
specific processor instructions are used to gurantee atomicity. Those
instructions are *not* generated by compiler when compiler sees POD type,
because they work much slower than usual ones.
> > keyword static will do bad things in C++03
>
> I'm well aware of that, and that's the reason why once_block_flag is
POD.
Even if you rewrite it to Boost.Atomic it is not safe to use it that way.
Back to the example:
{{{
if (!is_foo_inited) {
new (place_for_foo) foo_type(some parameters);
is_foo_inited = true;
}
}}}
Thread no1 checks for `!is_foo_inited`, enters the `if` block and starts
to execute the placement `new`. At that time thread no2 checks for
`!is_foo_inited` and enters the `if` block... That is not good, leads to
memory leaks and undefined behavior!
-- Ticket URL: <https://svn.boost.org/trac/boost/ticket/8730#comment:2> Boost C++ Libraries <http://www.boost.org/> Boost provides free peer-reviewed portable C++ source libraries.
This archive was generated by hypermail 2.1.7 : 2017-02-16 18:50:13 UTC