* The problem: POSIX functions that take an absolute time point as a timeout parameter use the CLOCK_REALTIME clock. This clock can be warped, particularly on personal or embedded devices, which makes it unsuitable for use for timeouts. A more suitable clock is CLOCK_MONOTONIC.
C++ standard classes such as std::condition_variable and std::timed_mutex treat the clock to use as being part of the wait operation, rather than as initialisation parameters of the underlying condition variable or mutex. This means that the solution currently exposed through pthread_condattr_setclock does not work well. * Affected functions: sem_timedwait pthread_mutex_timedlock pthread_cond_timedwait pthread_rwlock_timedrdlock pthread_rwlock_timedwrlock mq_timedreceive mq_timedsend (posix_trace_timedgetnext_event is also affected, but the header containing thatfunction is marked "obsolescent".) * Proposed solution: Create alternative forms of the affected functions that also take a parameter of type clockid_t to indicate the clock that should be used. The only clock that must be supported by implementations is CLOCK_REALTIME. Passing an unsupported clock will yield EINVAL. THis means that implementations that do not wish to support alternative clocks can just check the clock parameter is CLOCK_REALTIME and then call their existing function. Better implementations can support CLOCK_MONOTONIC, or perhaps even other clocks if appropriate. (The Linux system calls used to implement mq_clockreceive and mq_clocksend do not currently support CLOCK_MONOTONIC.) (It would be desirable to require CLOCK_MONOTONIC support too, but I wouldn't want this proposal to be stalled by implementors who will not or cannot support it.) * Function naming: Several proposals have been made for naming: ** 1. clock prefix sem_clock_timedwait pthread_mutex_clock_timedlock pthread_cond_clock_timedwait pthread_rwlock_clock_timedrdlock pthread_rwlock_clock_timedwrlock mq_clock_timedreceive mq_clock_timedsend ** 2. timed->clock sem_clockwait pthread_mutex_clocklock pthread_rwlock_clockrdlock pthread_rwlock_clockwrlock mq_clockreceive mq_clocksend pthread_cond_clockwait ** 3. onclock suffix sem_timedwait_onclock pthread_mutex_timedlock_onclock pthread_rwlock_timedrdlock_onclock pthread_rwlock_timedwrlock_onclock mq_timedreceive_onclock mq_timedsend_onclock pthread_cond_timedwait_onclock (suffices of simply _clock, or _cid were also proposed) * Next steps: I'm not sure what the process is for deciding on the naming, or in fact for any of this. Those of us that are keen to get the functionality would probably accept any of the names above (although personally I prefer 1 or 2 and I am not at all keen on the _cid suffix.) It would be easier to wait until the naming has been agreed before writing wording for the specification, but in theory a bit of search and replace ought to fix that. Do I need to request to get this onto the agenda for the conference call? Or is it too early for that? Should I add notes to http://austingroupbugs.net/view.php?id=1164 to include all the functions, or enter a new defect report? All guidance gratefully appreciated. Thanks. Mike.
