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

From: Anthony Williams (anthony_w.geo_at_[hidden])
Date: 2006-11-02 03:23:45

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

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

I've just never spent the time to really understand how boost.build works. If
there's issues, I'll have a go at finding them, if you like.

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

I guess we should review them, especially if we change the interface.

>> 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 thought the deep green signs were where the tests were marked as "expected
failure", yet passed anyway. I'll adjust status/expected_failures_markup.xml
so they're expected to pass.

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

Sure, I'll help. I'll drop you a note when I get on it.

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

Consistency with previous releases.

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

Correct.

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

try, timed, and plain lock are different functions, so can use different
methods for locking the mutex. In my implementation on Windows, there is no
penalty for adding timed locks to the mix, and try locks are really just a
single call to InterlockedCompareExchange. With a different implementation,
this might be different. On pthreads, we can just call the POSIX functions.

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

Yes, though I like Howard's idea of recursive_mutex being an adaptor, with
specializations for optimization.

Plus, I think we should have a shareable_mutex, which only supports simple
read locks and write locks and an upgradeable_mutex which also supports
upgradeable locks. Howard has both of these in his proposal. I really don't
like the convertible_shareable concept. A shareable_mutex would be
implementable using the POSIX rwlock stuff, whereas an upgradeable_mutex
requires a custom implementation. An upgradeable version also requires more OS
sync primitives on Windows, at least with my implementation.

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