On Oct 8, 2007, at 10:42 AM, Anthony Williams wrote:
Jeff Garland <jeff@crystalclearsoftware.com> writes:
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.
That's unfortunate.
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. At this point I feel it would be very important to have a reference implementation widely available to Boosters and others to play with so that any issues are shaken out while there's still time tweak things. Howard has been maintaining a reference implementation, but this is a call out to the broader thread development team (not sure who all that is now besides Anthony) to consider how we might formalize this into Boost.threads.
Thoughts?
I can help with a posix implementation. I don't have windows to develop on though.
The boost thread team is pretty much just me at the moment, though there's a reasonable level of interest from others (such as Peter Dimov).
I'm trying to update trunk to be have more of the C++0x interface at the moment. I've already integrated call_once (though I forgot only MSVC has _ReadWriteBarrier, and I haven't done the variadic arguments yet), and I'm currently working on the mutexes. I'm keen to get everything updated as much as possible before the 1.35 cutoff. I've got a reasonably up-to-date Windows implementation to use as a basis, and I've been working through the POSIX stuff.
Also, even though it's been punted to TR2, I want to get the read- write mutex back in --- I have a new implementation, and it's been missing since 1.32, so it would be good to get it back in the relese.
I can help on posix here too. I'm hoping it will look something like: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2406.html#shared_mu... or at least take some of those design decisions into consideration. The downside is that the above really needs rvalue ref for the upgrade- stuff. Possibilities include just not doing the upgrade stuff if rvalue ref is missing, or simulating move along the lines of what Dave has done. The standard containers are an integral part of the proposed std::thread package. Without move support in the standard containers useful structures such as vector<thread> are going to be missing. The lack of thread factory functions will also be unfortunate until compilers (such as gcc 4.3, boostcon and CodeWarrior 10) support returning move-only types from functions. -Howard