Re: [Boost-bugs] [Boost C++ Libraries] #11377: Boost condition variable always waits for system clock deadline

Subject: Re: [Boost-bugs] [Boost C++ Libraries] #11377: Boost condition variable always waits for system clock deadline
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2015-09-03 15:46:41


#11377: Boost condition variable always waits for system clock deadline
-------------------------------------+-------------------------------------
  Reporter: Dave Bacher | Owner: viboes
  <dbacher@…> | Status: assigned
      Type: Bugs | Component: thread
 Milestone: To Be Determined | Severity: Problem
   Version: Boost 1.56.0 | Keywords: condition variable,
Resolution: | clock
-------------------------------------+-------------------------------------

Comment (by David Bacher <dbacher@…>):

 Thanks for your attention.

> Does this fix you issue?

 Unfortunately, no. The issue is not with sleep operations, but with
 semaphore wait operations. When we wait on a semaphore and the system time
 changes, the wait does not return until the absolute time of the system
 clock reaches the deadline. Thus, if the system clock is set backwards
 while the process waits on a semaphore, the process may end up waiting
 longer than it should -- a 5 second wait may turn into a 1 minute wait if
 the system clock is set backwards by one minute. In our use case, we don't
 care about the absolute system time, we just want to time out after a
 specific duration.

> Could you resume what is the difference between your
 condition_variable_steady and the condition_variable?

 There is a minor change in condition_variable_steady to use the monotonic
 clock when initializing the semaphore and performing wait operations. This
 fixes the problem described above because the monotonic clock is not
 affected by changes in the system time.

-- 
Ticket URL: <https://svn.boost.org/trac/boost/ticket/11377#comment:4>
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:18 UTC