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

Subject: Re: [Threads-devel] Extend shared_mutex with support for priority policies?
From: Fredrik Orderud (forderud_at_[hidden])
Date: 2013-01-03 09:55:29

On Thu, Jan 3, 2013 at 2:06 AM, Vicente J. Botet Escriba <
vicente.botet_at_[hidden]> wrote:

>  Le 02/01/13 23:33, Fredrik Orderud a écrit :
>
>     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 idea of the test code was to illustrate that a failed timed_lock (which
should ideally be side-effect free) still affects reader vs. writer lock
acquisition order. If you run the test as-is- several times then
excusive_thread will be acquired first in ~90% of the times, while
shared_thread will be acquired first in ~90% of the time when
RESET_EXCLUSIVE_WAITING_BLOCKED has been defined.

Regards,
Fredrik