From: Roland Schwarz (roland.schwarz_at_[hidden])
Date: 2006-11-01 12:11:20
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
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:
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_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
Ok, have to study this in more detail.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk