Re: Adding a clockid_t parameter to functions that accept absolute timespecs

2018-11-27 Thread Tom Cherry
On Mon, Nov 26, 2018 at 10:20 AM Mike Crowe  wrote:
>
> On Sunday 04 November 2018 at 10:32:38 +, Mike Crowe wrote:
> > * Function naming:
> >
> > Several proposals have been made for naming:
>
> I only had one reply to the naming suggestions below, so I've combed
> through prior emails looking for preferences there. I apologise if I missed
> your preference. Please let me know! Results below.
>
> > ** 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
>
> Preferred by SC (in private email)
>
> > ** 2. timed->clock
> >  sem_clockwait
> >  pthread_mutex_clocklock
> >  pthread_rwlock_clockrdlock
> >  pthread_rwlock_clockwrlock
> >  mq_clockreceive
> >  mq_clocksend
> >  pthread_cond_clockwait
>
> Preferred by Mark Harris, Daniel Eischen.
>
> > ** 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
>
> Preferred by Tom Cherry (although I suspect that, like me, he's be happy
> with either of the others too if it meant that the feature was added!)

Yes, I'm fine with the others too if it gets these added.

>
> > All guidance gratefully appreciated.
>
> So, it looks like there isn't a clear favourite, but timed->clock has a
> slight majority. I plan to enter a new defect report to supersede
> http://austingroupbugs.net/view.php?id=1164 by covering all the above
> functions.

Sounds good to me.  Thanks for driving this forward.

>
> Thanks.
>
> Mike.



Re: Adding a clockid_t parameter to functions that accept absolute timespecs

2018-11-26 Thread Mike Crowe
On Sunday 04 November 2018 at 10:32:38 +, Mike Crowe wrote:
> * Function naming:
>
> Several proposals have been made for naming:

I only had one reply to the naming suggestions below, so I've combed
through prior emails looking for preferences there. I apologise if I missed
your preference. Please let me know! Results below.

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

Preferred by SC (in private email)

> ** 2. timed->clock
>  sem_clockwait
>  pthread_mutex_clocklock
>  pthread_rwlock_clockrdlock
>  pthread_rwlock_clockwrlock
>  mq_clockreceive
>  mq_clocksend
>  pthread_cond_clockwait

Preferred by Mark Harris, Daniel Eischen.

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

Preferred by Tom Cherry (although I suspect that, like me, he's be happy
with either of the others too if it meant that the feature was added!)

> All guidance gratefully appreciated.

So, it looks like there isn't a clear favourite, but timed->clock has a
slight majority. I plan to enter a new defect report to supersede
http://austingroupbugs.net/view.php?id=1164 by covering all the above
functions.

Thanks.

Mike.



Re: Adding a clockid_t parameter to functions that accept absolute timespecs

2018-11-04 Thread Daniel Eischen


> On Nov 4, 2018, at 5:32 AM, Mike Crowe  wrote:
> 
> * 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:
> 
> Severalproposals 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

My preference is option 2, as it's less wordy.

> ** 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)

--
DE



Re: Adding a clockid_t parameter to functions that accept absolute timespecs (was Re: C++ condition_variable and timed_mutex with steady_clock and pthreads)

2018-10-29 Thread Tom Cherry
On Sat, Oct 27, 2018 at 5:16 PM Mark Harris  wrote:
>
> On Sat, 27 Oct 2018 at 13:14, Mike Crowe  wrote:
>>
>> On Saturday 27 October 2018 at 15:26:07 -0400, Daniel Eischen wrote:
>> >
>> > > On Oct 27, 2018, at 12:14 PM, Mike Crowe  
>> > > wrote:
>> > > Looking through POSIX Base Specifications Issue 7, I
>> > > believe that the following other functions lack a way to use
>> > > CLOCK_MONOTONIC directly (and unlike pthread_cond_timedwait, I can see no
>> > > other way to make them do so):
>> > >
>> > > sem_timedwait
>> > > pthread_mutex_timedlock
>> > > pthread_rwlock_timedrdlock
>> > > pthread_rwlock_timedwrlock
>> > > mq_timedreceive
>> > > mq_timedsend
>> > > posix_trace_timedgetnext_event

The two message queue functions are directly implemented with a system
call on Linux at least, so I'm not sure that we should make new
versions of these unless we get the underlying system call to accept
different clocks.  I believe the posix tracing functions are marked as
obsolescent, so it seems to be best to leave them alone as well.

I agree with the creating these same variants for other four functions.

>> > >
>> > > (Many other functions that take a struct timespec treat it as a relative
>> > > timeout.) Of these, I've also found it necessary to implement a version 
>> > > of
>> > > sem_timedwait that used CLOCK_MONOTONIC.
>> > >
>> > > I originally named my function pthread_cond_timedwaitonclock since it
>> > > seemed that running the words together matched what was happening with
>> > > "timedwait". Others suggested that it should be
>> > > pthread_cond_timedwait_on_clock. I've tried to apply that style in the
>> > > function prototypes below.
>> >
>> > I think at least the "on_clock" should be "onclock" or just "clock" for 
>> > the same reason timedwait is not timed_wait.  Perhaps "_cid" for clock_id?
>> >
>> > Also, "clock_" is prefixed to nanosleep for similar functionality, perhaps 
>> > pthread_clock_cond_timedwait, etc instead of suffixing with "_clock" or 
>> > "_onclock"?
>>
>> I think that the clock prefix has some benefits. This would mean:
>>
>>  sem_clock_timedwait
>>  pthread_clock_mutex_timedlock
>>  pthread_clock_rwlock_timedrdlock
>>  pthread_clock_rwlock_timedwrlock
>>  mq_clock_timedreceive
>>  mq_clock_timedsend
>>  posix_clock_trace_timedgetnext_event
>>  pthread_clock_cond_timedwait
>>
>> Although, if you consider the prefix to contain multiple words then they
>> would be:
>>
>>  sem_clock_timedwait
>>  pthread_mutex_clock_timedlock
>>  pthread_rwlock_clock_timedrdlock
>>  pthread_rwlock_clock_timedwrlock
>>  mq_clock_timedreceive
>>  mq_clock_timedsend
>>  posix_trace_clock_timedgetnext_event
>>  pthread_cond_clock_timedwait
>
>
> How about just replacing "timed" with "clock"?
>
>  sem_clockwait
>  pthread_mutex_clocklock
>  pthread_rwlock_clockrdlock
>  pthread_rwlock_clockwrlock
>  mq_clockreceive
>  mq_clocksend
>  posix_trace_clockgetnext_event
>  pthread_cond_clockwait
>
> To me these names seem more appropriate, given that these calls wait until 
> the specified clock reaches the specified absolute value.  If the clock can 
> be set, or if an implementation were to support using these with, say, 
> CPUTIME clocks, then "timed" does not seem correct since it is not the time 
> taken by the call but rather the behavior of the specified clock that is 
> significant.
>
>  - Mark

pthread_cond_timedwait_onclock() is my top suggestion.  It makes it
clear that this is a modification to the parent
pthread_cond_timedwait() functions and that its semantics should be
identical with the change that it waits on the provided clock as
opposed to the one used during initialization.

I agree with moving this forward to the next required step.  We can
trivially implement them in the Android libc.



Re: Adding a clockid_t parameter to functions that accept absolute timespecs (was Re: C++ condition_variable and timed_mutex with steady_clock and pthreads)

2018-10-27 Thread Mark Harris
On Sat, 27 Oct 2018 at 13:14, Mike Crowe 
wrote:

> On Saturday 27 October 2018 at 15:26:07 -0400, Daniel Eischen wrote:
> >
> > > On Oct 27, 2018, at 12:14 PM, Mike Crowe 
> wrote:
> > > Looking through POSIX Base Specifications Issue 7, I
> > > believe that the following other functions lack a way to use
> > > CLOCK_MONOTONIC directly (and unlike pthread_cond_timedwait, I can see
> no
> > > other way to make them do so):
> > >
> > > sem_timedwait
> > > pthread_mutex_timedlock
> > > pthread_rwlock_timedrdlock
> > > pthread_rwlock_timedwrlock
> > > mq_timedreceive
> > > mq_timedsend
> > > posix_trace_timedgetnext_event
> > >
> > > (Many other functions that take a struct timespec treat it as a
> relative
> > > timeout.) Of these, I've also found it necessary to implement a
> version of
> > > sem_timedwait that used CLOCK_MONOTONIC.
> > >
> > > I originally named my function pthread_cond_timedwaitonclock since it
> > > seemed that running the words together matched what was happening with
> > > "timedwait". Others suggested that it should be
> > > pthread_cond_timedwait_on_clock. I've tried to apply that style in the
> > > function prototypes below.
> >
> > I think at least the "on_clock" should be "onclock" or just "clock" for
> the same reason timedwait is not timed_wait.  Perhaps "_cid" for clock_id?
> >
> > Also, "clock_" is prefixed to nanosleep for similar functionality,
> perhaps pthread_clock_cond_timedwait, etc instead of suffixing with
> "_clock" or "_onclock"?
>
> I think that the clock prefix has some benefits. This would mean:
>
>  sem_clock_timedwait
>  pthread_clock_mutex_timedlock
>  pthread_clock_rwlock_timedrdlock
>  pthread_clock_rwlock_timedwrlock
>  mq_clock_timedreceive
>  mq_clock_timedsend
>  posix_clock_trace_timedgetnext_event
>  pthread_clock_cond_timedwait
>
> Although, if you consider the prefix to contain multiple words then they
> would be:
>
>  sem_clock_timedwait
>  pthread_mutex_clock_timedlock
>  pthread_rwlock_clock_timedrdlock
>  pthread_rwlock_clock_timedwrlock
>  mq_clock_timedreceive
>  mq_clock_timedsend
>  posix_trace_clock_timedgetnext_event
>  pthread_cond_clock_timedwait
>

How about just replacing "timed" with "clock"?

 sem_clockwait
 pthread_mutex_clocklock
 pthread_rwlock_clockrdlock
 pthread_rwlock_clockwrlock
 mq_clockreceive
 mq_clocksend
 posix_trace_clockgetnext_event
 pthread_cond_clockwait

To me these names seem more appropriate, given that these calls wait until
the specified clock reaches the specified absolute value.  If the clock can
be set, or if an implementation were to support using these with, say,
CPUTIME clocks, then "timed" does not seem correct since it is not the time
taken by the call but rather the behavior of the specified clock that is
significant.

 - Mark


Re: Adding a clockid_t parameter to functions that accept absolute timespecs (was Re: C++ condition_variable and timed_mutex with steady_clock and pthreads)

2018-10-27 Thread Mike Crowe
On Saturday 27 October 2018 at 17:07:00 -0400, Daniel Eischen wrote:
> The nice thing about being able to set the clock in an attribute or some
> other way (e.g., pthread_set_preferred_clock) is that you only have to do
> it once, as opposed to potentially modifying lots of other code, even in
> libraries outside your scope. If you're writing a library that waits for
> events for the caller, you don't know what clock to use unless you add it
> to your API. Allowing the clock to be set on a per-thread (or even
> process) basis, might make things easier. Absolute times wouldn't really
> be helped by this though, as you still need to get the time for the
> correct clock.

I've written another blog post[1] that explains why the clock to use is a
property of the wait, although it doesn't address your suggestion directly.
The C++ standard library behaves as if "struct timespec" also contained
clockid_t, although the clock is part of the type so the compiler handles
it with no runtime overhead. This means that C++ libraries can be clock
agnostic.

I think that being able to set these things for a process or a thread makes
writing generic libraries harder. Some libraries may actively want to
choose which clock to use since their use of condition variables is
entirely invisible to the calling application. Others may want to expose
the clock to use. At the moment, neither is really possible for anything
but condition variables, and condition variables need to know the clock to
use in advance.

Thanks.

Mike.

[1] 
http://randombitsofuselessinformation.blogspot.com/2018/10/the-clock-used-for-waiting-on-condition.html



Re: Adding a clockid_t parameter to functions that accept absolute timespecs (was Re: C++ condition_variable and timed_mutex with steady_clock and pthreads)

2018-10-27 Thread Daniel Eischen


> On Oct 27, 2018, at 4:13 PM, Mike Crowe  wrote:
> 
>> On Saturday 27 October 2018 at 15:26:07 -0400, Daniel Eischen wrote:
>> 
>>> On Oct 27, 2018, at 12:14 PM, Mike Crowe  
>>> wrote:
>>> Looking through POSIX Base Specifications Issue 7, I
>>> believe that the following other functions lack a way to use
>>> CLOCK_MONOTONIC directly (and unlike pthread_cond_timedwait, I can see no
>>> other way to make them do so):
>>> 
>>> sem_timedwait
>>> pthread_mutex_timedlock
>>> pthread_rwlock_timedrdlock
>>> pthread_rwlock_timedwrlock
>>> mq_timedreceive
>>> mq_timedsend
>>> posix_trace_timedgetnext_event
>>> 
>>> (Many other functions that take a struct timespec treat it as a relative
>>> timeout.) Of these, I've also found it necessary to implement a version of
>>> sem_timedwait that used CLOCK_MONOTONIC.
>>> 
>>> I originally named my function pthread_cond_timedwaitonclock since it
>>> seemed that running the words together matched what was happening with
>>> "timedwait". Others suggested that it should be
>>> pthread_cond_timedwait_on_clock. I've tried to apply that style in the
>>> function prototypes below.
>> 
>> I think at least the "on_clock" should be "onclock" or just "clock" for the 
>> same reason timedwait is not timed_wait.  Perhaps "_cid" for clock_id?
>> 
>> Also, "clock_" is prefixed to nanosleep for similar functionality, perhaps 
>> pthread_clock_cond_timedwait, etc instead of suffixing with "_clock" or 
>> "_onclock"?
> 
> I think that the clock prefix has some benefits. This would mean:
> 
> sem_clock_timedwait
> pthread_clock_mutex_timedlock
> pthread_clock_rwlock_timedrdlock
> pthread_clock_rwlock_timedwrlock
> mq_clock_timedreceive
> mq_clock_timedsend
> posix_clock_trace_timedgetnext_event
> pthread_clock_cond_timedwait
> 
> Although, if you consider the prefix to contain multiple words then they
> would be:
> 
> sem_clock_timedwait
> pthread_mutex_clock_timedlock
> pthread_rwlock_clock_timedrdlock
> pthread_rwlock_clock_timedwrlock
> mq_clock_timedreceive
> mq_clock_timedsend
> posix_trace_clock_timedgetnext_event
> pthread_cond_clock_timedwait

Either one of those sounds good to me, I might prefer the latter if I had to 
choose.

>> There is still the ability to set the clock in the condition variable
>> attribute.  Should this be deprecated in lieu of the other functionality?
>> If not, which one takes precedence?  Should mutex attributes also grow
>> the ability to set the clock?  For the second question, I'd assume that
>> anything explicitly set in an "onclock" variant would override what was
>> specified in the attribute, or perhaps return an error instead.
> 
> I think it would be best for a supplied clock to override one set in the
> attributes. Returning an error would require extra state to be kept and
> checked, which would unnecessary complicate the implementation.
> 
> I don't think there's any hurry to deprecate the attribute, although that
> may make sense eventually.
> 
> I don't see any particular reason to add a clock attribute for mutexes if
> the above functions are added. Anyone who finds it laborious to pass the
> extra parameter can use a macro or wrapper function.

The nice thing about being able to set the clock in an attribute or some other 
way (e.g., pthread_set_preferred_clock) is that you only have to do it once, as 
opposed to potentially modifying lots of other code, even in libraries outside 
your scope.  If you're writing a library that waits for events for the caller, 
you don't know what clock to use unless you add it to your API.  Allowing the 
clock to be set on a per-thread (or even process) basis, might make things 
easier.  Absolute times wouldn't really be helped by this though, as you still 
need to get the time for the correct clock.

--
DE