Boost logo

Threads-Devel :

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
> <>
> <>,
> <>
> 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?
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]

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