Boost logo

Threads-Devel :

Subject: Re: [Threads-devel] RFC: 1st pthread shared_mutex refactoring patch
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2013-03-26 01:06:32


Le 24/03/13 18:24, Vicente J. Botet Escriba a écrit :
> Le 18/03/13 00:06, Fredrik Orderud a écrit :
>> On Sun, Mar 17, 2013 at 7:53 PM, Vicente J. Botet Escriba
>> <vicente.botet_at_[hidden] <mailto:vicente.botet_at_[hidden]>> wrote:
>>
>> After a more deep analysis, it seems to me that the encapsulated
>> data and the condition variables are quite correlated, that is,
>> changing the way the data is managed should have some impacts on
>> which condition variable should be notified or waited on. For
>> example, the implementation in boost/thread/v2/shared_mutex.hpp
>> uses only two condition variables instead of 3 in
>> boost/thread/pthread/shared_mutex.hpp.
>>
>>
>> Both pthread and win32 shared_mutex actually are quite similar in
>> both their state parameterization (pthread state_data is a subset of
>> win32) and usage of 3 condition variables/semaphores. I therefore
>> believe that they can be refactored to share significant parts of
>> their locking policy code.
>>
>> v2/shared_mutex indeed appears to be quite different. From what I can
>> see, it lacks the exclusive_waiting_blocked field. This makes me
>> question if it is capable of prioritizing write-lock request in favor
>> of read-lock requests, as the pthread and win32 equivalents are
>> doing. What are your thoughts on this?
> I suspect that Howard Hinnant prefered a fair solution.
After more deep insight I'm wondering if write_entered_ is not used to
ensure priority for writers. Note that write_entered_ doesn't mean that
the mutex is in exclusive mode but that some one has requested to be
in. The mutex is in exclusive mode when write_entered_ and n_readers_==0.

What do you think?

Best,
Vicente



Threads-Devel list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk