public inbox for glibc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug nptl/14717] New: Allow choice of clock source for calls to sem_timedwait() and pthread_mutex_timedwait().
@ 2012-10-14 11:58 grotlek at hotmail dot com
  2012-10-14 11:59 ` [Bug nptl/14717] " grotlek at hotmail dot com
                   ` (10 more replies)
  0 siblings, 11 replies; 12+ messages in thread
From: grotlek at hotmail dot com @ 2012-10-14 11:58 UTC (permalink / raw)
  To: glibc-bugs


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.


^ permalink raw reply	[flat|nested] 12+ messages in thread
end of thread, other threads:[~2021-08-11 20:13 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-10-14 11:58 [Bug nptl/14717] New: Allow choice of clock source for calls to sem_timedwait() and pthread_mutex_timedwait() grotlek at hotmail dot com
2012-10-14 11:59 ` [Bug nptl/14717] " grotlek at hotmail dot com
2012-10-15  3:46 ` bugdal at aerifal dot cx
2012-10-16 13:31 ` grotlek at hotmail dot com
2013-05-09 19:29 ` ondra at iuuk dot mff.cuni.cz
2013-05-21  8:20 ` ondra at iuuk dot mff.cuni.cz
2014-06-14 12:52 ` fweimer at redhat dot com
2014-10-23  9:18 ` Dean_Jenkins at mentor dot com
2015-10-07  8:54 ` sourceware.org at hovland dot cx
2021-08-11 16:05 ` sourceware-bugzilla at mac dot mcrowe.com
2021-08-11 16:19 ` sourceware.org at hovland dot cx
2021-08-11 20:13 ` adhemerval.zanella at linaro dot org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).