Ticket #7089 (closed Bugs: fixed)

Opened 5 years ago

Last modified 5 years ago

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

comment:1 Changed 5 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 5 years ago by viboes

  • Owner changed from anthonyw to viboes
  • Status changed from new to assigned

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 5 years ago by viboes

  • Milestone changed from To Be Determined to Boost 1.51.0

Committed in trunk 79327

comment:4 Changed 5 years ago by viboes

  • Status changed from assigned to closed
  • Resolution set to fixed

Committed revision [79373].

comment:5 Changed 5 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?


Add a comment

Modify Ticket

Change Properties
<Author field>
as closed
The resolution will be deleted. Next status will be 'reopened'

E-mail address and user name can be saved in the Preferences.

Note: See TracTickets for help on using tickets.