This is the mail archive of the
mailing list for the glibc project.
Re: The relative timeout in linuxthreads
- From: Marcus Brinkmann <Marcus dot Brinkmann at ruhr-uni-bochum dot de>
- To: "H . J . Lu" <hjl at lucon dot org>
- Cc: GNU C Library <libc-alpha at sources dot redhat dot com>
- Date: Thu, 7 Feb 2002 00:46:47 +0100
- Subject: Re: The relative timeout in linuxthreads
- References: <20020206152641.A31597@lucon.org>
On Wed, Feb 06, 2002 at 03:26:41PM -0800, H . J . Lu wrote:
> The current pthread interface only supports the timeout value in
> absolute time. The problem is under certain conditions, the clock
> can change. As the result, a thread may not time out in the right
> time. I will add a new interface to support the timeout value in
> relative time to solve our problems. Does anyone have any other
Mmmh. It doesn't seem to me that this added feature would give you a
satisfactionary robustness. Imagine that you (the program using pthreads)
receive a spurious wakeup, and the clock is changed just before you retrieve
the current time to recalculate the time you still have to wait. Then your
calculation will be wrong in any way. I can think of nothing that could
prevent this type of race from occuring.
If the clock changes discontinuously (into the future), the best guarantee
that can be made is to wake up any thread that requested to time out in the
skipped interval (and this is already required by POSIX). Setting the clock
back should never happen (that can seriously mess up things).
You were not very specific about the exact situation you want to fix, and
what guarantees you want to make, but the above is what I read from the
standard about absolute and relative time outs.
`Rhubarb is no Egyptian god.' Debian http://www.debian.org firstname.lastname@example.org
Marcus Brinkmann GNU http://www.gnu.org email@example.com