Subject: [Boost-bugs] [Boost C++ Libraries] #7089: BOOST_THREAD_WAIT_BUG limits functionality without solving anything
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2012-07-05 16:54:30
#7089: BOOST_THREAD_WAIT_BUG limits functionality without solving anything
----------------------------------------------+-----------------------------
Reporter: jason@⦠| Owner: anthonyw
Type: Bugs | Status: new
Milestone: To Be Determined | Component: thread
Version: Boost 1.50.0 | Severity: Problem
Keywords: BOOST_THREAD_WAIT_BUG timed_wait |
----------------------------------------------+-----------------------------
In upgrading from 1.45 to 1.50 I noticed the following, which I think
first appeared in 1.47:
[https://svn.boost.org/trac/boost/ticket/6130 Ticket 6130] reported a bug
that on linux a call to the following would return early:
{{{
condition_variable::timed_wait(lock, time)
}}}
Consequently, a code change was made to introduce BOOST_THREAD_WAIT_BUG
which forces at least a 1 millisecond sleep.
I think [https://svn.boost.org/trac/boost/ticket/6130 Ticket 6130] should
have been rejected since the reported behavior is an artifact of 'spurious
wake-ups' on linux and is solved by using the following:
{{{
condition_variable::timed_wait(lock, time, predicate)
}}}
This technique is referenced in the boost documentation.
I would like to see BOOST_THREAD_WAIT_BUG removed in order to eliminate
the minimum 1 millisecond wait time it introduced. BOOST_THREAD_WAIT_BUG
only masks the issue of spurious wake-ups as it can still happen if a
predicate is not used.
Potentially off-topic: It would be nice if condition_variable encapsulated
the predicate functionality on linux unless there's a valid reason that
eludes me. Encapsulation would have several benefits such as not
confusing the uninitiated, and avoiding the need for wrapper classes.
--Jason Aubrey
-- Ticket URL: <https://svn.boost.org/trac/boost/ticket/7089> 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