This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: The relative timeout in linuxthreads


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
> suggestions?

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.

Thanks,
Marcus


-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org
Marcus Brinkmann              GNU    http://www.gnu.org    marcus@gnu.org
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]