Modify

Ticket #7089 (closed Bugs: fixed)

Opened 22 months ago

Last modified 20 months 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:

Description

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

Attachments

Change History

comment:1 Changed 22 months 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 22 months 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 22 months ago by viboes

  • Milestone changed from To Be Determined to Boost 1.51.0

Committed in trunk 79327

comment:4 Changed 22 months ago by viboes

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

Committed revision [79373].

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

View

Add a comment

Modify Ticket

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


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

 
Note: See TracTickets for help on using tickets.