Opened 6 years ago

Closed 6 years ago

Last modified 6 years ago

#7089 closed Bugs (fixed)

BOOST_THREAD_WAIT_BUG limits functionality without solving anything

Reported by: jason@… Owned by: viboes
Milestone: Boost 1.51.0 Component: thread
Version: Boost 1.50.0 Severity: Problem
Keywords: BOOST_THREAD_WAIT_BUG timed_wait Cc:


In upgrading from 1.45 to 1.50 I noticed the following, which I think first appeared in 1.47:

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 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

Change History (5)

comment:1 Changed 6 years ago by jason@…

I meant to say that BOOST_THREAD_WAIT_BUG introduced a minimum wait time of 100 milliseconds on linux. --Jason Aubrey

comment:2 Changed 6 years ago by viboes

Owner: changed from Anthony Williams to viboes
Status: newassigned

You are right [78285] should not be merged to the release branch as not confirmed as a solution. I will roll back the change.

comment:3 Changed 6 years ago by viboes

Milestone: To Be DeterminedBoost 1.51.0

Committed in trunk 79327

comment:4 Changed 6 years ago by viboes

Resolution: fixed
Status: assignedclosed

Committed revision [79373].

comment:5 Changed 6 years ago by acidtonic

I had a similar bug on Windows with condition_variable::wait(lock) never returning after upgrading from 1.45 to 1.50.

I had to switch to a timed_wait(lock, time) and wait for a single timeout before being woke up.

In 1.45 the exact same project (confirmed via SVN history) does not exhibit this behavior and wait(lock) is enough.

MinGW on Windows XP, GCC 4.6.1.

Is this related by chance? Should I try 1.51 now?

Note: See TracTickets for help on using tickets.