[Bug nptl/14717] New: Allow choice of clock source for calls to sem_timedwait() and pthread_mutex_timedwait().

["grotlek at hotmail dot com" <sourceware-bugzilla at sourceware dot org>]

http://sourceware.org/bugzilla/show_bug.cgi?id=14717

             Bug #: 14717
           Summary: Allow choice of clock source for calls to
                    sem_timedwait() and pthread_mutex_timedwait().
           Product: glibc
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: nptl
        AssignedTo: unassigned@sourceware.org
        ReportedBy: grotlek@hotmail.com
                CC: drepper.fsp@gmail.com
    Classification: Unclassified


The OS maintains various clocks, such as CLOCK_REALTIME, CLOCK_MONOTONIC and
CLOCK_MONOTONIC_RAW.

CLOCK_REALTIME is defined as being the "wall clock" time, and as such, is
subject to being changed by NTP, calls to adjtime(), clock changes by the
system administrator, and jumps to and from DST.

PThread conditionals allow you to choose which clock the calls are synchronised
with; so pthread_cond_timedwait() can synchronise with CLOCK_MONOTONIC_RAW by
calling pthread_cond_init() with an appropriate attribute set.

However, no such facility exists for pthread_mutex_timedwait() or
sem_timedwait(). Looking at the source code to sem_timedwait(), it appears to
just translate the time given into a relative offset against gettimeofday() and
then call the underlying futex() system call.

Please add facility to semaphores and mutexes to allow a choice of clocks to
prevent the following scenario:

1. Program wants to call wait on a semaphore, but also process 1 second
'ticks'.
2. Program determines what the CLOCK_REALTIME time will be in 1 second, and
loads this value into a 'struct timespec'.
3. At this point in time, a clock change happens (DST/NTP/adjtime/admin
changing clock) - let's say DST changes the clock time by minus one hour.
4. Program calls sem_timedwait() with its timespec set to what the program
believes is 1 second.
5. sem_timedwait() calls gettimeofday() and prepares its relative offset, which
is now 1 hour and 1 second. It could feasibly not wake up for another hour.

This scenario isn't good if the tick is, for example, to process updates to a
UI. (It could even be to update a clock time :P).

So to repeat, please add functionality to allow a C program to choose the clock
source for calls to sem_timedwait() and pthread_mutex_timedwait().

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.