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-26 08:44:04

#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:7 andysem]:
> Replying to [comment:6 apolukhin]:
> > Replying to [comment:5 andysem]:
> > > No, it won't. Since it's POD, its initialization is performed during
 the static initialization stage, which happens before any dynamic
 initialization. See 3.6.2 [basic.start.init] in the standard.
> >
> > This is not correct for *local objects with static storage duration*,
 see 6.7 of C++03:
> >
> > So you can not have 100% guarantee for that.
> Ok, you have a point. But note that once_block_flag::uninitialized is 0
 and zero initialization for local static objects is still performed before
 any other initialization. Most compilers will simply ignore the
 initializer for this reason. But I guess, it can be just removed from the
 macro definition to avoid the confusion and guarantee the correct

 OK, you've convinced me.

 May I ask a few more questions. Why there is so many things 'reinvented'
 in Boost.Log? Foe example I can see light_rw_mutex.cpp,
 thread_safe_queue.cpp, thread_id.cpp, thread_specific.cpp and others...
 They are all already implemented in Boost and tested for a long time. Why
 don't you use them?

Ticket URL: <>
Boost C++ Libraries <>
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