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

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

[grotlek at hotmail dot com]

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.

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

[grotlek at hotmail dot com]

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

Grotlek <grotlek at hotmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |grotlek at hotmail dot com

-- 
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.

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

[bugdal at aerifal dot cx]

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

Rich Felker <bugdal at aerifal dot cx> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugdal at aerifal dot cx

--- Comment #1 from Rich Felker <bugdal at aerifal dot cx> 2012-10-15 03:46:15 UTC ---
DST does not affect the clock whatsoever.

-- 
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.

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

[grotlek at hotmail dot com]

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

--- Comment #2 from Grotlek <grotlek at hotmail dot com> 2012-10-16 13:30:59 UTC ---
Accepted - I was inferring from the Debian man page for clock_gettime() - as
the "wall clock" time does change for DST. However, the issue does still apply
because the clocks used for programmatic threads are subject to change with the
race condition I described, even if DST isn't one of the factors that influence
it (the other three do, and those are directly stated by the man pages).

I'll paste the descriptions of the clocks from the man page here, as it does
add to the conversation.

---

Sufficiently recent versions of glibc and the Linux kernel support  the
 following clocks:

 CLOCK_REALTIME
        System-wide  clock  that  measures real (i.e., wall-clock) time.
        Setting this clock requires appropriate privileges.  This  clock
        is  affected by discontinuous jumps in the system time (e.g., if
        the system administrator manually changes the clock), and by the
        incremental adjustments performed by adjtime(3) and NTP.

 CLOCK_MONOTONIC
        Clock  that  cannot  be  set and represents monotonic time since
        some unspecified starting point.  This clock is not affected  by
        discontinuous  jumps  in  the  system  time (e.g., if the system
        administrator manually changes the clock), but  is  affected  by
        the incremental adjustments performed by adjtime(3) and NTP.

 CLOCK_MONOTONIC_RAW (since Linux 2.6.28; Linux-specific)
        Similar  to  CLOCK_MONOTONIC, but provides access to a raw hard‐
        ware-based time that is not subject to NTP  adjustments  or  the
        incremental adjustments performed by adjtime(3).

-- 
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.

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

[ondra at iuuk dot mff.cuni.cz]

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

OndrejBilka <ondra at iuuk dot mff.cuni.cz> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ondra at iuuk dot
                   |                            |mff.cuni.cz

--- Comment #3 from OndrejBilka <ondra at iuuk dot mff.cuni.cz> 2013-05-09 19:29:21 UTC ---
We must pass a time to kernel. For specifing time in other formats you would
need add appropriate choice in syscalls.

-- 
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.

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

[ondra at iuuk dot mff.cuni.cz]

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

OndrejBilka <ondra at iuuk dot mff.cuni.cz> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |enhancement

-- 
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.

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

[fweimer at redhat dot com]

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

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
              Flags|                            |security-

-- 
You are receiving this mail because:
You are on the CC list for the bug.

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

[Dean_Jenkins at mentor dot com]

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

Dean Jenkins <Dean_Jenkins at mentor dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |Dean_Jenkins at mentor dot com

--- Comment #4 from Dean Jenkins <Dean_Jenkins at mentor dot com> ---
Is there any news on allowing CLOCK_MONOTONIC to be used with sem_timedwait() ?

The issue we are facing on an embedded ARM project is that sem_timedwait() can
misbehave when the system clock aka CLOCK_REALTIME is modified such as by a GPS
timebase. Typically the system does not have a real RTC and starts at the EPOCH
of 1970 and then sometime after boot the system clock gets adjusted to the
present day time. This causes a misbehaviour of sem_timedwait() because an
absolute timespec is used such as a time in 1970.

I think a lack of a monotonic clock for functions such as sem_timedwait() is a
serious limitation in embedded systems.

I read reports on the Internet about sem_timedwait() not having a monotonic
clock but no solutions or workarounds appear to be written in the reports. Does
anyone have a workaround because this seems to be a long-standing
issue/limitation ?

Thanks.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

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

[sourceware.org at hovland dot cx]

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

Jay <sourceware.org at hovland dot cx> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sourceware.org at hovland dot cx

--- Comment #5 from Jay <sourceware.org at hovland dot cx> ---
I'm using wait-calls and have problems if another process changes the time.
Would very much appreciate it if monotonic was supported somehow.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

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

[sourceware-bugzilla at mac dot mcrowe.com]

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

Mike Crowe <sourceware-bugzilla at mac dot mcrowe.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sourceware-bugzilla at mac dot mcr
                   |                            |owe.com

--- Comment #10 from Mike Crowe <sourceware-bugzilla at mac dot mcrowe.com> ---
I believe that this is addressed by the addition of the POSIX-proposed
sem_clockwait() and pthread_mutex_clocklock() functions in
6615f77978bd12f06157fae8d4523b3ec475062b and
9d20e22e46d891b929a72b0f35586e079eb083fd respectively. These are both available
from glibc v2.30 onwards.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

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

[sourceware.org at hovland dot cx]

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

--- Comment #11 from Jay <sourceware.org at hovland dot cx> ---
Yes indeed. I have verified that both om them work :)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

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

[adhemerval.zanella at linaro dot org]

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

Adhemerval Zanella <adhemerval.zanella at linaro dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
   Target Milestone|---                         |2.30
                 CC|                            |adhemerval.zanella at linaro dot o
                   |                            |rg
         Resolution|---                         |FIXED

--- Comment #12 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
It was indeed provided by glibc 2.30.

-- 
You are receiving this mail because:
You are on the CC list for the bug.