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.Le 18/03/13 00:06, Fredrik Orderud a écrit :
I suspect that Howard Hinnant prefered a fair solution.On Sun, Mar 17, 2013 at 7:53 PM, Vicente J. Botet Escriba <vicente.botet@wanadoo.fr> 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?