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

From: Roland Schwarz (roland.schwarz_at_[hidden])
Date: 2006-11-01 16:06:08

Anthony Williams wrote:
> 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?

I am still working to get bbv2 straight, there are still some issues.
But since I vaguely remember that you already said, that writing
jam does not belong to your favored tasks, I'm afraid I'll have
to continue this. Then rw of course. But luckily enough you are
already on this. Then testing and checking if everything works.
I started with the examples.

Btw.: What do you think about the examples? Shouldn't we also
review them? Put better comments inside? Are they really
instructive for a user?

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

Wow! Today we are completely green! Only a shade of gray on an old
compiler. Yesterday I remember having seen a red light for
intel- vc71- win- 9.1. Hopefully this is not a spurious error that
hides some problems. Do you know how we can turn off the "unexpectedly
passing" deep green signs? E.g. I have made the tss cleanup beeing
not present for native threads a warning, since I believe this is an
optimization only since everything will run without it. In the worst
case the application is left with a bounded memory-leak. And when
using boost created thread even this leak will not be present.
Could you please help with this?

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

True, it was pruned from 1.33, but not from head (fortunately).
Can you help me getting it out off the documentation? I am not sure if
it sufficient to pull out a single file, because it might be referenced
from several places. I suggest doing this again first only for the
RC_1_34_0 branch. Please put me a short note in case you are starting
with this, so we do not end up editing the same files concurrently.

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

Thank you. :-) This indeed keeps me motivated!
Yes of course I would like to share the crowd.

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

Very fine! I am looking for this eagerly.

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

It is not the differences about the interfaces that puzzles me, but the
fact that

recursive_timed_mutex::scoped_lock lk(m);

is the same as:

mutex::scoped_lock lk(m);

This has the potential to unsettle new users of the lib. (I also needed
some time to understand this concept, and did only after having read the
code.)

In this respect I like Howards proposal, simply templating the lock on
the mutex type. It suffices if it is impossible to instantiate e.g.:

mutex m;
scoped_timed_lock lk(m)

What is the benefit of having the locks inside the mutex declaration?

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

This might be true for the mutex, but not the locks, yes?
But beware, wouldn't we give away the possibility to e.g optimize a
plain mutex more than a full blown timed_mutex?
On the other hand try, timed, and plain are just variations of
timeout: 0 sec, x sec, inifinite.
Do you have any findings about loss of optimizability? At least I
think any op-sys waitable object has the timeout feature anyways.

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

Agreed.
So we would end up with mutex and recursive_mutex, yes?

Roland