Re: [Threads-devel] RFC: 1st pthread shared_mutex refactoring patch

Subject: Re: [Threads-devel] RFC: 1st pthread shared_mutex refactoring patch
From: Fredrik Orderud (forderud_at_[hidden])
Date: 2013-03-25 07:13:34

On Sun, Mar 24, 2013 at 6:24 PM, Vicente J. Botet Escriba <
vicente.botet_at_[hidden]> wrote:

>  As I said you, the patch I send to you didn't respect some invariants. I
> have made a commit in trunk that contains some of your changes, and mainly
> the assertion I have added. I would introduce the changes one by one in
> order to ensure that the invariants are not broken.
>
> Committed revision 83546.
>

Thank you Vicente. I thinks the extra asserts are a good idea have better
control over invariants, and agree on your preference for a gradual
approach.

Personally, I think the signaling logic between unlock_shared and
unlock_upgrade_and_lock is a bit more complicated than necessary. I've
prepared a patch that simplified the logic while eliminating upgrade_cond,
so that there are only 2 condition variables left (a step towards the "v2"
HH implementation). The attached patch utilizes a temporary state_data
object in unlock_upgrade_and_lock to achieve atomic update of state without
risk of side-effects during wait.
As for overhead, unlock_shared now also notifies exclusive_cond when
upgrade and exclusive_waiting_blocked are set (regardless of shared_count).
This additional overhead should, however, be offset by the fact that
shared_cond no longer needs to be notified in unlock_shared.
All "thread" tests still pass on my Win7/x64 computer with
BOOST_THREAD_PROVIDES_GENERIC_SHARED_MUTEX_ON_WIN defined.

What do you think?

Regards,
Fredrik