Anthony Williams wrote:
That was when the goal was a simple reimplementation under the BSL. Now Bill's code is under the BSL, the goalposts have moved to focusing on a potential interface for the new standard. Are you in agreement that this is a worthwhile goal?
Well, yes in principle, but what about the ongoing platform split? It is not finished yet. And then we should concentrate on getting 1.34 ready shouldn't we? I have to say that it is a rather thankless task to do the work for the split, just to possibly see that everything is superfluous, because we are doing a new interface. (I am also just doing this in my spare time, and I also rather like thinking about new stuff.) I am really inclined to abandon work on thread_rewrite if we instead opt. to concentrate on a new interface.
Howard does quite a good job in N2094:
http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2006/n2094.html
To be honest I didn' yet study this in every detail.
I like the idea of maintaining the mutex_type::scoped_lock members, but they could just be typedefs to lock<mutex_type>, as they can just delegate to the appropriate public member functions.
I prefer lock being templated on the mutex because I think the lock class is the more important object because of its enforcement of the scoped usage pattern.
If you would like , I'll be happy to oblige.
Possibly yes :-)
I am not sure we need separate types for try_ and timed_ variants of a given mutex, but if we need them for one platform (because a mutex without the options can be simplified), it might be worth providing typedefs or delegating classes for other platforms.
Why not simply class scoped_lock class scoped_try_lock : public scoped_lock class scoped timed_lock : public scoped_try_lock Or are you afraid of the virtual functions this implies? As far as I understand Howards draft puts this into a single class that is capable of all variants, like can be expressed by a timeout parameter too: 0 : try, number : timed, infinite : basic
Howard seems to have gone "all moveable", and his proposal allows for upgrading and downgrading locks by moving them around --- you upgrade an upgradeable to exclusive by move-constructing an exclusive lock from your upgradeable one.
Ok, have to study this in more detail. Roland