Re: [Threads-devel] Extend shared_mutex with support for priority policies?

Subject: Re: [Threads-devel] Extend shared_mutex with support for priority policies?
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2013-01-02 20:06:22

Le 02/01/13 23:33, Fredrik Orderud a écrit :
> On Mon, Dec 31, 2012 at 1:50 AM, Vicente J. Botet Escriba 
> <vicente.botet_at_[hidden] <mailto: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/%7Ehinnant/>
>
>     http://home.roadrunner.com/~hinnant/bloomington/shared_mutex.html
>     <http://home.roadrunner.com/%7Ehinnant/bloomington/shared_mutex.html>,
>     www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2406.html
>     <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2406.html>
>     and http://home.roadrunner.com/~hinnant/mutexes/locking.html
>     <http://home.roadrunner.com/%7Ehinnant/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?
I can not add more that I did for the moment. Anyway, I don't see what 
your test is proving. Maybe you could remove this flag and see how it 
behaves, is it more fair?
>
>>     * 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
>
>
> _______________________________________________
> threads-devel mailing list
> threads-devel_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/threads-devel