Re: [boost] [thread] Questions/concerns about recent thread lib changes

From: Johan Nilsson (r.johan.nilsson_at_[hidden])
Date: 2007-10-21 07:31:15

"Peter Dimov" <pdimov_at_[hidden]> skrev i meddelandet news:010601c811a7$df700410$6407a80a_at_pdimov2...
> Johan Nilsson:
> 
>> I believe there are "relative" deadlines as well. Suppose you are 
>> receiving
>> data that should arrive at a certain frequency; if that frequency is e.g.
>> 20Hz, a reasonable value for emitting a data timeout warning could be 2
>> periods => 50*2 = 100ms (in this case, a background thread would put each
>> data item in a common buffer when it arrives, and signal the cv for some
>> other entity to process it).
> 
> You may well start out with a relative timeout value, but it's converted to 
> an absolute deadline just once, at the start, on a high level that doesn't 
> usually deal with thread primitives. Then you propagate the absolute 
> deadline through code. Something like:
> 
> bool f( abstime const & dl )
> {
>    return g( dl ) && h( dl );
> }
> 
> (guaranteed wait-free rollback on failed h omitted for simplicity :-) ).
> 
> Even for the simple condvar wait case, you have a preceding mutex lock which 
> needs to also respect the deadline.

So the decision to use absolute times are due to implementation details? Ok, sounds reasonable.

The problem for me with having absolute times in the interface is that it does not show my (the programmer's) intent to wait for a relative time. On the other hand, having relative times in the interface while using absolute times in the implementation is sort of like lying to the clients, as it actually changes the semantics a bit ... (just thinking out loud).

What would be really nice to have would be something like a high-res std::monotonic_time (assuming proper platform support).

> 
> Relative timeouts on the primitive level are typically coarse (without a 
> specific correct value) and usually meant to catch deadlocks.

Does "on the primitive level" mean deep within the thread library code?

> 
> Side note: to support the deadline use case, all timed operations have to 
> include an overload taking an absolute value.
> 
>>> An additional relative timeout overload in the cases where it's
>>> appropriate could work, but the current templatization does not allow
>>> it unless concepts come into play.
>>
>> Well, where would it not be appropriate?
> 
> I think that the non-predicate version of condition::timed_wait should not 
> allow a relative timeout since this would make it even more error-prone than 
> it is now.

Of course. I've been almost excusively been using the predicate-based version myself, so I didn't reflect on the problems when using timed_wait within the context of a loop. Until now, that is.

As a side note:

I actually took the time to read through n2320, modulo the reference part. A really great job, which actually made me smile at some point (first time ever when reading this kind of document)!

Pretty much the only thing that I could complain about (and this was only a minor annoyance) was the usage of the "this_thread" namespace. I recognize the analogy to "this", but "current_thread" was the first name that came to mind (implemented as a class with static members instead of a namespace).

I guess "this" is less ambiguous than "current", but the latter feels like a more natural alternative. Perhaps this is just my Win32 heritage.

/ Johan