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

Subject: Re: [Threads-devel] Extend shared_mutex with support for priority policies?
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2012-12-30 19:50:03

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_at_[hidden] <mailto:vicente.botet_at_[hidden]>> 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