|
|
Threads-Devel : |
Subject: Re: [Threads-devel] Extend shared_mutex with support for priority policies?
From: Fredrik Orderud (forderud_at_[hidden])
Date: 2012-12-20 11:24:20
On Mon, Dec 17, 2012 at 9:38 PM, Vicente J. Botet Escriba <
vicente.botet_at_[hidden]> wrote:
> Le 15/12/12 19:16, Fredrik Orderud a écrit :
>
> The current "fair" shared_mutex implementation is great in the sense that
>> it neither favors readers nor writers. This is probably a good property in
>> most situations.
>>
>> However, there are situations where either reader or writer
>> prioritization can be beneficial. In particular, I'm working on a project
>> where the locking could be significantly stricter without risking
>> introducing deadlocks if read-locks could be guaranteed to have priority
>> over write-locks. I fully understand that a read- or write-priority
>> implementation might have a bigger overhead compared to the existing "fair"
>> shared_mutex implementation, but that is unlikely to be a problem for me.
>>
>> Is anyone in the boost community experiencing similar problems and/or is
>> there any interest in extending shared_mutex with support for different
>> priority policies?
>>
>> I think that it will be better to create specific shared mutex classes
> with read/write/fifo priorities. The interface of these classes must mimic
> boost::shared_mutex so that we are able to use them with the shared_lock
> and upgrade_lock.
>
> I have no time to work on this now but if you provide a first
> implementation I could help you to finish it so that it can be introduced
> in Boost.Thread.
>
Thank you Vicente.
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. The policies could probably also be implemented
with a class hierarchy if preferred. For simplicity, neither
upgrade-locking nor lock_for/until calls are yet implemented.
FIFO-prioritization have also been skipped, since I suspect it would
require a more advanced "queue" datastructure with higher complexity.
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?
Thanks in advance,
Fredrik Orderud