Re: Make sem_timedwait use FUTEX_CLOCK_REALTIME (bug 18138)

[Joseph Myers <joseph at codesourcery dot com>]

On Wed, 18 Mar 2015, Torvald Riegel wrote:

> On Wed, 2015-03-18 at 00:28 +0000, Joseph Myers wrote:
> > If a relative
> > timeout is passed to the kernel, it is interpreted according to the
> > CLOCK_MONOTONIC clock, and so fails to meet that POSIX requirement in
> > the event of clock changes.
> 
> Thanks for realizing the clock change issue, which I had overlooked.
> 
> (I'd say that strictly speaking, this is "only" a QoI issue though,
> because we give no hard guarantees around timing.)

I think you could produce a test that demonstrates an unambiguous bug, not 
depending (for the assertion that the observed results are buggy) on any 
particular latency requirements not in POSIX.  Say, one thread performs 
sem_timedwait, while the other sets the clock forward past the timeout 
specified in the sem_timedwait call (required to cause sem_timedwait to 
terminate with ETIMEDOUT), then posts the semaphore.  If sem_timedwait 
terminates successfully, that means that the requirement "If the absolute 
time requested at the invocation of such a time service is before the new 
value of the clock, the time service shall expire immediately as if the 
clock had reached the requested time normally." was not met.  With the 
existing code using relative timeouts, such a test would in practice have 
sem_timedwait succeed, while POSIX does not permit it to succeed.

-- 
Joseph S. Myers
joseph@codesourcery.com