[Boost-users] boost::interprocess::interprocess_semaphore::timed_wait - how to do a relative wait

[Jean-Sebastien Stoezel]

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

[Ion Gaztañaga]

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
_______________________________________________
Boost-users mailing list
Boost...@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users

[Viatchesla...@h-d-gmbh.de]

> 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

[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.

Even the boost APIs that seem to allow relative waits (wait_from_now) all end up specifying an absolute wake up time.

Jean

[Viatchesla...@h-d-gmbh.de]

On Thu, 17 Feb 2011 16:02:06 +0100, Jean-Sebastien Stoezel
<js.st...@gmail.com> wrote:

> 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 <boost/date_time/posix_time/posix_time.hpp>
#include <boost/interprocess/sync/interprocess_semaphore.hpp>

int main()
{
struct timespec td_start,td_end;
boost::interprocess::interprocess_semaphore sem(0);
boost::posix_time::ptime
t(boost::posix_time::microsec_clock::universal_time());
printf("Start waiting\n");
clock_gettime(CLOCK_MONOTONIC, &td_start);
bool ret = sem.timed_wait(t + boost::posix_time::seconds(30));
clock_gettime(CLOCK_MONOTONIC, &td_end);
printf("Finished waiting %s, waited %d seconds\n", ret == false ? "due
to timeout" : "due to some other semaphore event",
td_end.tv_sec-td_start.tv_sec);
return 0;
}

compiled with gcc 4.3.2 on SUSE 11.1 (usual x86) against boost 1.45, it
happens to run just fine:
vsysolts:~/test/boost (1) > g++ -g -O0 -I/home/vsysolts/boost/boost_1_45_0
-L/home/vsysolts/boost/boost_1_45_0/stage/lib test2.cpp -lboost_date_time
-lpthread && a.out
Start waiting
Finished waiting due to timeout, waited 30 seconds

I have set the system clock 5 minutes back while it was waiting. It has
waited for around 30 seconds, definitely not for about 5 minutes.

Btw the native semaphores are not affected by system time on my system too.

So what are you objecting against *exactly*?