“David Gibbs” <dagibbs@qnx.com> wrote in message
news:dkg6ah$dh2$3@inn.qnx.com…
Robert Kindred <> RKindred@swri.edu> > wrote:
The way pthreadcond_timedwait works is that you give it absolute time.
This is one of the stupidest “decisions” I’ve seen come out of the POSIX
spec. Why, oh why, would anyone want to wait until an ABSOLUTE time for
a timeout on a blocking synch call? (This is defined this way for at
Because it allows you to start the countdown at a chosen point before you
call the function, rather than an unspecified point after. The stupid part
is not that it’s absolute; the stupid part is that it uses the
user-adjustable CLOCK_REALTIME rather than CLOCK_MONOTONIC by default. But
since CLOCK_MONOTONIC is optional, it would’t be a very good default… I
agree that it’s an inconvenience to have to call pthread_condattr_setclock()
and three or four other extra functions just because you want to be able to
do reliable timed waits on your condvar, but I think I could come up with a
few things in POSIX that are clearly stupider…
least condvars, mutexes, and semaphores that I’ve looked at.) Almost
always you want to wait a relative time… if the operation took too
long, give up and try again… so you always grab a local time, add
your relative time to it, then wait for the absolute time. Ugh, ugh,
Well, how would you write a timed condvar loop if you had to use a relative
timer? How would you write it if checking your condition could took a hard
to predict amount of time, for instance because it involved disk access or
ran at a relatively low priority?
ugh, ugh, ugh. Now, at least on most UNIX systems (including QNX),
you won’t get bitten… because we store/use the time in seconds since
January 1st, 1970; and daylight savings is only an input/output
modification.
It’s guaranteed on any POSIX system. Presumably, a program using the POSIX
threads API should be able to rely on it.
BTW Here’s the relevant text from the POSIX Rationale:
Timed Wait Semantics
An absolute time measure was chosen for specifying the timeout parameter for
two reasons. First, a relative time measure can be easily implemented on top
of a function that specifies absolute time, but there is a race condition
associated with specifying an absolute timeout on top of a function that
specifies relative timeouts. For example, assume that clock_gettime()
returns the current time and cond_relative_timed_wait() uses relative
timeouts:
clock_gettime(CLOCK_REALTIME, &now)
reltime = sleep_til_this_absolute_time -now;
cond_relative_timed_wait(c, m, &reltime);
If the thread is preempted between the first statement and the last
statement, the thread blocks for too long. Blocking, however, is irrelevant
if an absolute timeout is used. An absolute timeout also need not be
recomputed if it is used multiple times in a loop, such as that enclosing a
condition wait.
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.
Timed Condition Wait
The pthread_cond_timedwait() function allows an application to give up
waiting for a particular condition after a given amount of time. An example
of its use follows:
(void) pthread_mutex_lock(&t.mn);
t.waiters++;
clock_gettime(CLOCK_REALTIME, &ts);
ts.tv_sec += 5;
rc = 0;
while (! mypredicate(&t) && rc == 0)
rc = pthread_cond_timedwait(&t.cond, &t.mn, &ts);
t.waiters–;
if (rc == 0) setmystate(&t);
(void) pthread_mutex_unlock(&t.mn);
By making the timeout parameter absolute, it does not need to be recomputed
each time the program checks its blocking predicate. If the timeout was
relative, it would have to be recomputed before each call. This would be
especially difficult since such code would need to take into account the
possibility of extra wakeups that result from extra broadcasts or signals on
the condition variable that occur before either the predicate is true or the
timeout is due.
http://www.opengroup.org/onlinepubs/009695399/functions/pthread_cond_timedwait.html