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:26:18

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

 There is no direct counterpart for thread_safe_queue, aside from the
 recently added Boost.Lockfree. Even then, Boost.Lockfree containers have
 restrictions on the element types that are not compatible with Boost.Log.
 It is possible to change the implementation to employ Boost.Lockfree, but
 the resulting code will be less efficient and also it adds an unnecessary
 dependency, so I don't think this is reasonable.

 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.

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