Boost logo

Boost :

Subject: Re: [boost] Condition Variables, POSIX signals and system time changes
From: Anthony Williams (anthony.ajw_at_[hidden])
Date: 2012-01-11 02:41:58


On 10/01/12 07:35, Johan Borkhuis wrote:
> I came across the following issue with condition variables. I don't know
> if this is an issue with my application or with Boost condition variables.
>
> First my setup. I am using Linux on an ARM system, running Boost 1.47. My
> application needs accurate timing, and for this I use a POSIX timer using
> SIGRTMIN. This part is not something that I can control, it is an external
> library that implements this. I use condition variables are a timing
> mechanism with in my software.
>
> When I use condition variables without the POSIX timer there is no
> problem. The timing continues correctly, even if I change the time forward
> or backward.
>
> When I start the POSIX timer the condition variable does not time-out when
> I change the time backward. It only times out when the original time (plus
> timeout) is reached.
>
> The code I use to create the condition variable:
>
> boost::mutex m;
> boost::condition_variable cond;
> boost::unique_lock<boost::mutex> lk(m);
> cond.timed_wait(lk, duration);
>
> I tested this also by extracting the code from Boost and implementing this
> inline. This gave the same results. When I changed the clock of the
> pthread condition variable to monotonic (call to
> pthread_condattr_setclock(&condattr, CLOCK_MONOTONIC)) the result was OK
> again.
>
> Is this an issue with my implementation, can I change some setting or is
> this a (known) issue with the Boost condition variables?

I'm not aware of this specific issue, but I am aware that there are
issues around clocks and timeouts with condition variables. The boost
condition variables are wrappers around pthread_cond_t on POSIX systems
such as linux. A pthread_cond_t can only use one clock for timeouts.
Boost uses the system "real time" clock, but as you have seen you can
also use the monotonic clock on systems that support it.

There are issues both ways with how to handle timeouts based on a clock
other than the one being used --- e.g. timed_wait with an absolute time
from the system clock will have issues when used on a condition variable
that uses the monotonic clock if the clock is adjusted, as the condvar
will wait for the original duration, rather than waking earlier or later
as appropriate.

It appears that on your system, if you create a timer then it affects
the way that condition variable waits are timed out when the clock is
adjusted.

Anthony

-- 
Author of C++ Concurrency in Action     http://www.stdthread.co.uk/book/
just::thread C++11 thread library             http://www.stdthread.co.uk
Just Software Solutions Ltd       http://www.justsoftwaresolutions.co.uk
15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk