Austin Group Defect Tracker

Aardvark Mark III


Viewing Issue Simple Details Jump to Notes ] Issue History ] Print ]
ID Category Severity Type Date Submitted Last Update
0001216 [1003.1(2016)/Issue7+TC2] System Interfaces Comment Enhancement Request 2018-11-26 18:53 2018-11-27 16:02
Reporter mikecrowe View Status public  
Assigned To ajosey
Priority normal Resolution Open  
Status Under Review  
Name Mike Crowe
Organization
User Reference
Section pthread
Page Number 0
Line Number 0
Interp Status ---
Final Accepted Text
Summary 0001216: Adding clockid parameter to functions that accept absolute struct timespec timeouts
Description POSIX contains several functions that support waiting with an absolute
timeout passed as a struct timespec. This time must almost always be
measured against CLOCK_REALTIME. (pthread_cond_timedwait also supports a
single alternative clock specified at construction time via
pthread_condattr_setclock.)

Embedded systems and desktop computers may not have a good source of
accurate time, particularly at boot. This can result in CLOCK_REALTIME
warping by a large amount when the real time is known. In such situations,
CLOCK_REALTIME is not a good choice for expressing timeouts. A member of
the Android libc team has reported[1] that this has been the cause of real
world bugs in Android applications. I've worked on software at different
companies where we had to work around this problem.

The C++ standard provides std::condition_variable::wait_until and
std::timed_mutex::try_lock_until methods which support arbitrary clocks.
Current implementations that build upon POSIX convert these clocks to
CLOCK_REALTIME, which can cause race conditions when CLOCK_REALTIME is
warped. The C++ standard requires the clock to be specified at the time of
the wait, which means that pthread_condattr_setclock isn't useful.

The above problems can be solved by adding variants of the affected
functions that take an extra clockid_t parameter to indicate the clock that
should be used. Initially, implementations would be required to only
support passing CLOCK_REALTIME which would make adding support
straightforward. Support for CLOCK_MONOTONIC would be suggested, and
implementations would be free to support other clocks if they wished.

This proposal is the result of a thread[2] on the mailing list and my
original defect report[3] only covering pthread_cond_timedwait.

Various naming options for the new functions were discussed[4] and the
following names are based on one of the more popular options. In all cases
the clock immediately precedes the timespec timeout.

int
pthread_mutex_clocklock(
    pthread_mutex_t *restrict mutex,
    clockid_t clock,
    const struct timespec *restrict abstime)

int
pthread_rwlock_clockrdlock(
    pthread_rwlock_t *restrict rwlock,
    clockid_t clock,
    const struct timespec *restrict abstime)

int
pthread_rwlock_clockwrlock(
    pthread_rwlock_t *restrict rwlock,
    clockid_t clock,
    const struct timespec *restrict abstime)

int
pthread_cond_clockwait(
    pthread_cond_t *restrict cond,
    pthread_mutex_t *restrict mutex,
    clockid_t clock,
    const struct timespec *restrict abstime)

int
sem_clockwait(
    sem_t *restrict sem,
    clockid_t clock,
    const struct timespec *restrict abstime)

ssize_t
mq_clockreceive(
    mqd_t mqdes, char *restrict msg_ptr,
    size_t msg_len,
    unsigned int *restrict msg_prio,
    clockid_t clock,
    const struct timespec *restrict abs_timeout)

int
mq_clocksend(
    mqd_t mqdes, const char *restrict msg_ptr,
    size_t msg_len, unsigned int msg_prio,
    clockid_t clock,
    const struct timespec *restrict abs_timeout)

These functions all behave the same as their "timed" equivalents, but
measure the timeout against the specified clock rather than CLOCK_REALTIME.

If passed an unsupported clock, these functions indicate failure in the
same way as their "timed" equivalents and return/set errno to ENOTSUP as
required.

Support for a clock by one function does not require that the clock be
supported by any of the others.

[1] www.mail-archive.com/austin-group-l@opengroup.org/msg02902.html">https://www.mail-archive.com/austin-group-l@opengroup.org/msg02902.html [www.mail-archive.com/austin-group-l@opengroup.org/msg02902.html" target="_blank">^]
[2] www.mail-archive.com/austin-group-l@opengroup.org/msg02813.html">https://www.mail-archive.com/austin-group-l@opengroup.org/msg02813.html [www.mail-archive.com/austin-group-l@opengroup.org/msg02813.html" target="_blank">^]
[3] http://austingroupbugs.net/view.php?id=1164 [^]
[4] www.mail-archive.com/austin-group-l@opengroup.org/msg03034.html">https://www.mail-archive.com/austin-group-l@opengroup.org/msg03034.html [www.mail-archive.com/austin-group-l@opengroup.org/msg03034.html" target="_blank">^]
Desired Action The addition of the above functions, or ones that provide equivalent functionality.
Tags No tags attached.
Attached Files

- Relationships
related to 0001164New Correct C++11 std::condition_variable requires a version of pthread_cond_timedwait that supports specifying the clock 

-  Notes
(0004171)
nick (manager)
2018-11-27 16:02

As a reminder, the Austin Group procedures (see https://opengroup.org/austin/docs/austin_sd6.txt) [^] state:

New Work Items


From time to time, a defect report may propose new work
items that are outside the scope of maintenance of the Austin Group
specifications. This section addresses how these are handled.

The Austin Group is not a development body for new material apart from
integration issues arising from the merger of the approved standards
that were the Base documents into the revision.

The Austin Group expects to take a similar approach for a future revision.
Thus if a defect report raises the possibility of new interfaces
for inclusion, the standard response will be that it is out of scope
for either a TC or Interpretation, and that if the new material were
to meet the some criteria it may be considered for inclusion in a
future revision subject to the agreed scope determined at that time,
although there is no guarantee.

The recommended criteria for development of new interfaces to enable
them to be considered for inclusion in a future revision are as follows:

1.There must be a written specification that has undergone a formal
consensus based approval process and is suitable for inclusion.

Parties interested in submitting new work items through one of the
three organizations within the Austin Group (The Open Group, IEEE, ISO/IEC)
should contact the appropriate Organizational Representative for further
information and advice on how each organization handles new work items.
Submissions from other organizations will also be considered.
Items 2 through 4 below apply to all submissions regardless of
origin.

2.There must be an implementation, preferably a reference implementation.

3.The specification must be "sponsored" by one of three organizations
(The Open Group, IEEE, ISO/IEC) within the Austin Group, i.e. they would
support and champion its inclusion.

4.Submitters must provide an outline plan of the editing instructions to
merge the document with the Austin Group specifications, and assistance
to the Austin Group editors as required to complete the merger.

- Issue History
Date Modified Username Field Change
2018-11-26 18:53 mikecrowe New Issue
2018-11-26 18:53 mikecrowe Status New => Under Review
2018-11-26 18:53 mikecrowe Assigned To => ajosey
2018-11-26 18:53 mikecrowe Name => Mike Crowe
2018-11-26 18:53 mikecrowe Section => pthread
2018-11-26 18:53 mikecrowe Page Number => 0
2018-11-26 18:53 mikecrowe Line Number => 0
2018-11-27 09:23 geoffclare Project 1003.1(2008)/Issue 7 => 1003.1(2016)/Issue7+TC2
2018-11-27 09:23 geoffclare Relationship added related to 0001164
2018-11-27 16:02 nick Note Added: 0004171


Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker