Le 30/12/12 21:25, Fredrik Orderud a écrit :

On Thu, Dec 20, 2012 at 11:44 PM, Vicente J. Botet Escriba <vicente.botet@wanadoo.fr> wrote:
Le 20/12/12 17:24, Fredrik Orderud a écrit :
Attached is an early "draft" implementation of "shared_pri_mutex" with support for the following prioritization policies: UNSPECIFIED_PRIORITY, EXCLUSIVE_PRIORITY and SHARED_PRIORITY. Associated test code is attached in main.cpp. The implementation is based on a stripped-down version of boost/thread/pthread/shared_mutex.hpp, and implements policies through an enum template argument.
This is a good starting point. Do you expect that shared_pri_mutex< UNSPECIFIED_PRIORITY> behaves as shared_mutex?
Yes, that was the idea. Note that my internal state_data struct does differ a bit from the ones in the win32 & pthread shared_mutex implementations, since I couldn't fully understand them. In particular, I've extended the 1-bit/bool exclusive_waiting_blocked flag into an exclusive_request_count counter.

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

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?
* Why does state_data differ so much between the pthread and win32 implementations? In particular, why are the shared_waiting/exclusive_waiting counters only present in the win32 impl.? Does this mean that win32 vs. pthread shared_mutex behaves differently?
I guess not, but I don't master the implementations completely.
* 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.
<snip>
Could you (or someone else) please provide some feedback on the "shared_pri_mutex" concept, and realism of getting a revised/extended implementation incorporated into boost::thread at some point?
I would prefer to integrate into Boost an implementation that takes in account upgrade-locking and timed operations. As soon as we have a complete and correct implementation, with enough test and documentation we could integrate them in a release. The documentation will need a motivation, why do we need them? If you can work on some of these subjects the integration could be do sooner.
Agree. I just need some time to dig into the details on the existing implementations.

Please, send me any question you could have. I will try to answer if I know or try to understand otherwise.
 
Anyway, for the time been I have some minor remarks:


Fully agree with you comments. Consider them "done". :-)
 
Great.
Maybe it is worth creating a Trac ticket.
 That might be, but I will first need to spend some time first to implement a proper proposal that also incorporates the "upgrade" aspect. This will take some time.

I know. This is why I'm encouraging you to go to a complete implementation ;-)
Thanks for all the constructive comments Vicente.
Your are welcome.

Vicente