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.