On Sun, Mar 24, 2013 at 6:24 PM, Vicente J. Botet Escriba <vicente.botet@wanadoo.fr> 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.

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