This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: linuxthreads, POSIX 1003.1j and CLOCK_MONOTONIC
- From: Brian Kuschak <bkuschak at yahoo dot com>
- To: "H. J. Lu" <hjl at lucon dot org>
- Cc: libc-alpha at sources dot redhat dot com
- Date: Wed, 10 Jul 2002 19:12:43 -0700 (PDT)
- Subject: Re: linuxthreads, POSIX 1003.1j and CLOCK_MONOTONIC
--- "H. J. Lu" <hjl@lucon.org> wrote:
> On Wed, Jul 10, 2002 at 12:08:47PM -0700, Brian
> Kuschak wrote:
> > POSIX 1003.1j defines a new clock attribute for
> > condition variables, along with a new clock type,
> > CLOCK_MONOTONIC. This attribute allows
> > pthreads_cond_timedwait() functions to specify
> their
> > timeout using a clock which never jumps forward or
> > backwards. This prevents a race condition which
> > occurs in the present gettimeofday()
> implementation if
> > the system clock is stepped forward or backwards.
> >
> > What is the plan for adding POSIX 1003.1j support
> to
> > GNU linuxthreads? Is there anyone out there who
> has
> > implemented such a solution already?
> >
>
> I added pthread_mutex_timedlock_rel,
> pthread_cond_timedwait_rel,
> pthread_rwlock_timedrdlock_rel,
> pthread_rwlock_timedwrlock_rel and
> sem_timedwait_rel to our glibc. They take a relative
> timeout.
>
Relative timeout have problems. What if your thread
gets preempted between computation of the relative
timeout and the call to *_timedwait*. Your thread
will block for too long. They also make it difficult
to go back to sleep for the correct amount of time if
the pthreads call is interrupted (EINTR).
__________________________________________________
Do You Yahoo!?
Sign up for SBC Yahoo! Dial - First Month Free
http://sbc.yahoo.com