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
> 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:
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,
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 Williams Software Developer Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk