Re: [Boost-bugs] [Boost C++ Libraries] #8730: Race condition in once_block.hpp

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 20:28:35

#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 andysem):

 Replying to [comment:2 apolukhin]:
 >
 > 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.

 I repeat, all modifications to the flag are done in a thread-safe manner.
 There is no need for explicit atomic ops in this case, because only the
 fast path check is done unprotected. The secondary check and all
 modifications are done under the mutex lock, which ensures all the
 necessary memory barriers.

 Do you have a particular use case that may show breakage with the current
 implementation of once_block? On what hardware? With references to the
 code, if possible.

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

 That is not the code that is present in once_block.hpp/cpp, nor it is
 intended to be that way. I'm not using Boost.Atomic in that code for very
 specific reasons. Please, do not digress to problems in hypothetical code
 in this report.

-- 
Ticket URL: <https://svn.boost.org/trac/boost/ticket/8730#comment:3>
Boost C++ Libraries <http://www.boost.org/>
Boost provides free peer-reviewed portable C++ source libraries.