Boost logo

Threads-Devel :

Subject: Re: [Threads-devel] Extend shared_mutex with support for priority policies?
From: Fredrik Orderud (forderud_at_[hidden])
Date: 2013-01-02 17:33:19

On Mon, Dec 31, 2012 at 1:50 AM, Vicente J. Botet Escriba <
vicente.botet_at_[hidden]> wrote:

> Le 30/12/12 21:25, Fredrik Orderud a écrit :
> * Are you aware of any documentation for the shared_mutex locking
> algorithm? In particular, I'm curious about the precise workings of
> exclusive_waiting_blocked.
> The single references I have are at
> and

Thank you Vicente.

> The implementation in Boost.Thread is a little bit different. Now that you
> request for exclusive_waiting_blocked, it seems to be used to give priority
> to the first exclusive ownership as as soon as it is set on lock
> operations, all the shared and upgrade operations are blocked. Anthony
> could you confirm?

The reason why I'm asking is that exclusive_waiting_blocked is reset on
failed timed_lock() requests. This seems a bit strange in my eyes, since
this should be a no-op and there might still be blocked exclusive-lock
requests present. I also won't be surprised if there are issues related to
the reset of the flag in unlock() and unlock_shared() when several
exclusive-lock requests queued up. I've attached some test code that
demonstrates change in behaviour after a failed timed_lock() request (not
the best code, but it should illustrate my point).

In my eyes, it would be more natural to instead have a counter for the
number of exclusive-lock requests (as in my shared_pri_mutex code sample
from 2012-12-17). This should make it easier to get consistent behaviour on
failed xxx_lock() requests and facillitate implementation of different
priority policies. It might, however, be some clever aspect of
exclusive_waiting_blocked that I'm overlooking or don't understand. Any
comments on this?

   * The win32 imp. appears to be "better" in that it's lockless (except
> for semaphores), whereas pthread has an internal mutex protecting all
> methods (with condition variables). Are there any specific reasons why the
> pthread imp. isn't also lockless?
> I think it could be beneficial to first take some steps towards
> unifying/deduplicating the shared_mutex implementations before adding more
> "priority policy" complexity into the mix.
> The win32 implementation is not complete. I think we should concentrate on
> the generic implementation (located now in the pthread directory but that
> doesn't depends at all on pthread) and then go to a specific and possible
> more efficient implementation on windows or pthread.

That makes sense. I agree on focusing on the "pthread" implementation first.


Threads-Devel list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at