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

From: Anthony Williams (anthony_w.geo_at_[hidden])
Date: 2006-11-01 10:47:57

Roland Schwarz <roland.schwarz_at_[hidden]> writes:

> Anthony Williams wrote:
>> 
>> OK, I'll provide a generic implementation of my algorithm.... Attached.
>> 
>
> Since you are obviously deviating from the current interface (although
> I thought we agreed that we leave everything as is for the moment), 

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?

> may
> I kindly ask you to put together a short description or prototype of
> the planned new interface?

Howard does quite a good job in N2094:

http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2006/n2094.html

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.

If you would like , I'll be happy to oblige.

> The current implementation partly is so much unreadable because Bill
> tried hard to express common behavior (try and timed) by means of
> templates instead of inheritance. Are you planning to mimic this?

I intend to try and keep the implementation as clear and simple as possible,
which includes eliminating duplication. Sometimes this means templates,
sometimes inheritance.

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.

> Also you are providing scoped_read_lock, scoped_write_lock but no
> scoped_read_write_lock. Is my assumption correct that you renamed this
> to scoped_upgradeable_lock?

Yes. This is one area where I'm not sure I agree with Howard. 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. Though I think this is a useful facility, it is quite a drastic change
from the status quo, and at the moment I favour simple "upgrade" and
"downgrade" member functions.

Anthony
-- 
Anthony Williams
Software Developer
Just Software Solutions Ltd
http://www.justsoftwaresolutions.co.uk