Re: [boost] [thread] Roadmap for RW locks ?

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
> 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