[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <455D7CDD.9000202@privacy.net>
Date: Fri, 17 Nov 2006 10:11:57 +0100
From: John <me@...vacy.net>
To: linux-kernel@...r.kernel.org
CC: tglx@...esys.com, mingo@...e.hu, johnstul@...ibm.com
Subject: Incorrect behavior of timer_settime() for absolute dates in the past
Hello everyone,
[ NOTE: Email is a bit-bucket. I *do* monitor the mailing list. ]
I'm playing with the POSIX timers API. My platform is x86 running Linux
2.6.18.1 patched with the high-resolution timer subsystem.
http://www.tglx.de/hrtimers.html
I'm seeing unexpected behavior from timer_settime().
int timer_settime(timer_t timerid, int flags,
const struct itimerspec *value, struct itimerspec *ovalue);
timer_settime() is used to arm a timer. If the TIMER_ABSTIME flag is
set, then the timer should fire when the appropriate clock reaches the
date specified by value. If that date is in the past, the timer should
fire immediately.
The Open Group Base Specifications Issue 6 states:
http://www.opengroup.org/onlinepubs/009695399/functions/timer_getoverrun.html
"If the flag TIMER_ABSTIME is set in the argument flags, timer_settime()
shall behave as if the time until next expiration is set to be equal to
the difference between the absolute time specified by the it_value
member of value and the current value of the clock associated with
timerid. That is, the timer shall expire when the clock reaches the
value specified by the it_value member of value. If the specified time
has already passed, the function shall succeed and the expiration
notification shall be made."
In my tests, when timer_settime() is called with an expiration date in
the past, the timer still takes some time to fire.
Here's a run-down of the code provided as an attachment:
I switch to a SCHED_RR scheduling policy. In other words, whenever my
process wants the CPU, it gets it. (No other SCHED_RR or SCHED_FIFO
processes on the system.) I mask the signal that will be delivered on
timer expiration. I then arm a timer with an expiration date in the
past, check whether the signal is pending, and block waiting for the
signal. I then print how long I've had to wait.
# ./a.out
RESOLUTION=1 ns
NOW=969.735545919
SLEEPING 1 SECOND...
NOW=970.735581398
NOW=970.735613525
NOW=970.735749017
nsdiff=135492 ns i.e. 135.5 µs
Any ideas?
Regards,
John
View attachment "abstimerTEST.c" of type "text/plain" (2066 bytes)
Powered by blists - more mailing lists