boost::interprocess::interprocess_semaphore::timed_wait - how to do a relative wait
Hi: I'm using boost::interprocess::interprocess_semaphore::timed_wait and boost::interprocess::message_queue::timed_received. I have to specify an absolute time to give up waiting/receiving. This works in most cases, except my application sometimes needs to adjust the PC clock. If the PC clock is adjusted backwards in time, then these function wait longer than they should (since the end time is fixed in the future). Ideally I would like to provide an absolute time instead, which would be independent of the time of day? The API doesn't seem to allow this. How can I do this? I guess I could also use a deadline timer (ASIO). Any help on this would be appreciated. Thanks, Jean
El 14/02/2011 23:41, Jean-Sebastien Stoezel escribió:
How can I do this? I guess I could also use a deadline timer (ASIO).
It's not supported. POSIX also specifies that how discontinuities should be treated on condition variables: "For cases when the system clock is advanced discontinuously by an operator, it is expected that implementations process any timed wait expiring at an intervening time as if that time had actually occurred." For windows, relative timeouts might be easy to implement, but not in POSIX. Best, Ion
This works in most cases, except my application sometimes needs to adjust the PC clock. If the PC clock is adjusted backwards in time, then these function wait longer than they should (since the end time is fixed in the future).
Given that and what Ion says: "For cases when the system clock is advanced discontinuously by an operator, it is expected that implementations process any timed wait expiring at an intervening time as if that time had actually occurred." I would consider the behavior (prolonged waiting) as a bug. Well, its even kind of showstopper one. Imagine a boost-based programm running into issue when ntp daemon adjust the clock backwards. Can you please distill a small test case demonstrating the problem for your environment? -- Slava
Hi:
I won't provide an example, just either do a sleep, or call a timed wait on
a semaphore, mutex etc... with a long enough timeout (say 60s). While your
thread is waiting, change the clock of your computer backwards by say 2h.
Your thread will be waiting 2h instead of 60s.
Even the boost APIs that seem to allow relative waits (wait_from_now) all
end up specifying an absolute wake up time.
Jean
On Thu, Feb 17, 2011 at 2:17 AM,
This works in most cases, except my application sometimes needs to adjust
the PC clock. If the PC clock is adjusted backwards in time, then these function wait longer than they should (since the end time is fixed in the future).
Given that and what Ion says: "For cases when the system clock is advanced discontinuously by an operator, it is expected that implementations process any timed wait expiring at an intervening time as if that time had actually occurred."
I would consider the behavior (prolonged waiting) as a bug. Well, its even kind of showstopper one. Imagine a boost-based programm running into issue when ntp daemon adjust the clock backwards. Can you please distill a small test case demonstrating the problem for your environment?
-- Slava
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
On Thu, 17 Feb 2011 16:02:06 +0100, Jean-Sebastien Stoezel
Hi:
I won't provide an example, just either do a sleep, or call a timed wait on a semaphore, mutex etc... with a long enough timeout (say 60s). While your thread is waiting, change the clock of your computer backwards by say 2h. Your thread will be waiting 2h instead of 60s.
Well, I tried the following test program:
#include
participants (3)
-
Ion Gaztañaga -
Jean-Sebastien Stoezel -
Viatcheslav.Sysoltsev＠h-d-gmbh.de