Re: [boost] Future of Boost.Thread, date-time, and C++0x

From: Phil Endecott (spam_from_boost_dev_at_[hidden])
Date: 2007-10-08 12:51:59

Jeff Garland wrote:
> At the Kona meeting (just finished) the standard committee made very 
> significant progress on threading for C++0x -- voting in a proposal written by 
> Howard H, Beman, Anthony Williams, myself, and others -- subject to wording 
> changes to be made by a small drafting committee.  Basically we were in 
> agreement on semantics, but even after several late night drafting sessions 
> people weren't happy with the standardeze.
>
> While much of the proposal is based on Boost.thread it has some serious 
> departures in the way mutexes and guard interfaces work, it's use of date-time 
> types for clock/timing interfaces and such.

This reminds me: I thought I posted something about this when Howard 
sent his proposal to this list, but it seems to have been lost in an 
email black-hole.  Howard's code included timed operations that are 
templated on the time type, which (presumably) allows an implementation 
to provide versions for each of that platform's standard time types.  
This reminded me of some presentations about power saving at 
LinuxConf.EU: apparently reducing the number of timer interrupts is 
greatly beneficial to increasing energy efficiency, and one way to 
achieve this is to align all applications' periodic wakeups.  Very 
often, we want to timeout after "about a second" but will actually 
specify a timeout value of "exactly 1.0000000 seconds"; if the API 
allowed us to indicate, for example, "between 0.1 and 1.5 seconds", or 
"1 second +/- 10%", then some hidden power-saving wakeup-alignment 
algorithm could be applied.  (Equally, you could imagine situations 
where it would be beneficial to spread out wakeups, rather than 
grouping them.)  So does the proposal allow this sort of thing to be 
done, by supplying a "time range" type?

There's also the question of whether the implementation style of a 
mutex and/or its locks can somehow be chosen, e.g. between a spin-lock 
(best when the probability of contention is very low) and an 
OS-supported mutex (best when the probability of contention is 
greater).  Having substantially improved the performance of shared_ptr 
on ARM-linux by moving from pthreads to an atomic-asm implementation, 
I'm considering doing the same to Boost.Threads on that platform.  
However, the distinction between locks around very short critical 
sections (e.g. a pair of variables that must be updated atomically) and 
longer-duration locks needs to be made somehow.

Any thoughts?

Regards,

Phil.