On Mon, Dec 31, 2012 at 1:50 AM, Vicente J. Botet Escriba <vicente.botet@wanadoo.fr> 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