Sent from my iPhone

> On Oct 6, 2018, at 5:43 PM, Daniel Eischen <> wrote:
>> On Oct 6, 2018, at 3:00 PM, Mike Crowe <> wrote:
>> Thank you for your detailed responses and patch links. I'm sorry it's taken
>> me so long to respond. I was waiting to see if there were any other 
>> responses.
> Aside from what may be needed by the implementation for the proposed C++ 
> standard functionality, I don't understand why initializing a mutex or 
> condition variable (via the attribute) with the desired clock is not 
> sufficient.  I can see adding an analogue to pthread_condattr_setclock() for 
> a mutex attribute, but what is the real need to provide both real-time and 
> monotonic sleeps on the same mutex or condition variable?  Initialize them 
> once with the clock you want, and be done with it.
> I'd almost rather see the timespec changed (controversial much?!) to add the 
> clock id rather than keep adding new interfaces to support waits/sleeps on 
> different clocks.  Or maybe to provide a hint to the implementation as to 
> what clock to use on a per-thread basis via something like 
> pthread_attr_setpreferredclock() and pthread_setpreferredclock().  If you had 
> these, I suppose you could implement the C++ functionality by saving the 
> current thread's preferred clock, setting it to the desired clock, calling 
> the mutex lock or CV wait function, then restoring the thread's clock before 
> returning to the caller.
> --
> DE

Reply via email to