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

From: Anthony Williams (anthony_w.geo_at_[hidden])
Date: 2006-11-01 12:35:36

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

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

We likely need a platform split whatever interface we go with, since pthreads
is quite different at the API level to Windows, even if the same facilities
are on offer. What's left to do? How can I help?

> And then we should concentrate on getting 1.34 ready shouldn't we?

If there's something that needs doing for 1.34, it should take priority. I
really was under the impression that there was nothing to do here, since the
existing code is now under the BSL, and the tests all pass. Are them
outstanding bugs that need fixing? Am I missing something?

I had missed the fact that the existing rwmutex was still there, even though
it was removed from 1.33, so it's quite possible that I'm missing something
else too.

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

Sorry you're finding it thankless. How can I help?

> I am really inclined to abandon work on thread_rewrite if we
> instead opt. to concentrate on a new interface.

It would be a shame if we lost you. Wouldn't you be interested in developing
the new interface?

>> If you would like , I'll be happy to oblige.
>
> Possibly yes :-)

OK, I'll try and draft something. No doubt it will make things clearer to me,
too.

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

The scoped_xxx_lock classes all have slightly different interfaces at the
moment, which makes me a bit uncomfortable. For example, a scoped_try_lock
constructed with a mutex may or may not lock, whereas a scoped_lock
constructed with a mutex always locks, and a scoped_timed_lock cannot be
constructed with just a mutex. OTOH, all three scoped_xxx_lock classes have a
constructor that takes a bool as a second parameter and will always lock if
that parameter is true.

However, that wasn't what I was referring to. I was thinking about mutex,
try_mutex and timed_mutex, which I think can really be one and the same
class. Empty inheritance works fine if you want distinct types, provided you
don't need them to be POD.

recursive_mutex requires a recursion count, so can justify being a separate
class.

For read/write mutexes, a simple read/write implementation is simpler than an
upgradeable one (and in my implementation requires one less semaphore) so it
might make sense to have two varieties. Howard calls them shar(e)able_mutex
and upgrad(e)able_mutex in N2094.

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