[Boost-bugs] [Boost C++ Libraries] #7422: condition_variable performance regression

Subject: [Boost-bugs] [Boost C++ Libraries] #7422: condition_variable performance regression
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2012-09-25 20:01:44


#7422: condition_variable performance regression
-----------------------------------------+----------------------------------
 Reporter: maxim.yegorushkin@… | Owner: anthonyw
     Type: Bugs | Status: new
Milestone: To Be Determined | Component: thread
  Version: Boost 1.51.0 | Severity: Regression
 Keywords: condition_variable |
-----------------------------------------+----------------------------------
 In boost versions prior to 1.45 condition_variable was a zero-overhead
 thin wrapper over pthread_cond_t.

 In version 1.45 an internal mutex was added to condition_variable to
 improve thread cancellation support as described elsewhere (can't add the
 link to gmane archive because Trac thinks it's spam).

 Since version 1.45 calling condition_variable::wait*() and
 condition_variable::notify*() lock the internal mutex. Doing so causes
 performance regressions for latency sensitive applications that don't use
 thread cancellation. To put it in other words, condition_variable was
 essentially turned into condition_variable_any.

 Could the old version of condition_variable be added back please?

 A good idea seems to be requiring a macro, for example
 BOOST_THREADS_REQUIRE_THREAD_CANCELLATION, to be defined for
 condition_variable to include the internal mutex or be an alias for
 condition_variable_any. A call to thread::interrupt() would fail at
 compile time if BOOST_THREADS_REQUIRE_THREAD_CANCELLATION is not defined.
 Things may get more complicated if any compiled boost libraries use
 condition_variable though.

-- 
Ticket URL: <https://svn.boost.org/trac/boost/ticket/7422>
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:10 UTC