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?