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 09:44:44

#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:9 andysem]:
 > Replying to [comment:8 apolukhin]:
 > >
 > > 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?
 >
 > Because for various reasons these implementations do not fit the
 pressing requirements of the library.
 >
 > light_rw_mutex is more lightweight in terms of compile times and
 probably run times (I haven't benchmarked it thoroughly) than
 shared_mutex.
 >
 > Unlike thread::id, thread id attribute provides ids equivalent to those
 you would typically see in debugger or system monitoring tools (i.e. some
 notion of a system thread ids), which simplifies greatly debugging.
 >
 > TLS, as it is implemented in Boost.Log, guarantees maximum performance
 the underlying system provides (unlike Boost.Thread implementation which
 provided O(N) complexity of every access to the thread specific value at
 some point; I think it's O(log(N)) now, but it is still worse than the
 typical O(1) of the system TLS).
 >
 > I did propose some of these custom implementations to the respective
 libraries but there was little interest. I may try again in the future
 though.

 All the changes sound good. Why don't you cooperate with Vicente Botet
 (current maintainer of Boost.Thread) and propose your changes to him? I
 don not really wish to see two different thread libraries in Boost - they
 make resulting users code bigger and require more effort for maintaining.

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