|
|
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 :
>
Questions:
> * 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 http://home.roadrunner.com/~hinnant/
>
> http://home.roadrunner.com/~hinnant/bloomington/shared_mutex.html,
> www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2406.html and
> http://home.roadrunner.com/~hinnant/mutexes/locking.html
>
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.
Regards,
Fredrik