Roland Schwarz <roland.schwarz@chello.at> 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