Re: [Threads-devel] RFC: 1st pthread shared_mutex refactoring patch

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