TDPL, shared data, and Phobos

[Graham St Jack]

On 23/07/10 10:23, Sean Kelly wrote:
> awishformore Wrote:
>
>    
>> On 22/07/2010 01:49, Robert Jacques wrote:
>>      
>>> Have you tried core.sync.rwmutex? Also, please remember that CREW locks
>>> are not composable and can easily lead to dead-locks.
>>>        
>> Afaik, the current rwmutex is a wrapper around two separate mutexes (one
>> for readers, one for writers) and you have to decide whether readers or
>> writers get precedence, meaning that ether all writers in the queue have
>> to wait if just one reader has to write or all writers in the queue have
>> to wait if there is a single reader comes up.
>>
>> This is very unlike the behaviour I would like to see; I would expect
>> readers and writers to be in the same queue, meaning the only difference
>> between the rw and the normal mutex would be that all subsequent readers
>> in the queue can read at the same time.
>>      
> ReadWriteMutex exposes a read and write interface, but there certainly aren't two actual mutexes underneath.  It's true that the implementation doesn't explicitly maintain a queue, but this is intentional.  If readers and writers in the queue have different thread priorities set, those priorities should be honored, and it's pointless to write all that code in druntime when the OS takes care of it for us.  Instead, those waiting for access to the mutex all block on a condition variable and whoever wakes up first wins.  It's up the OS to make sure that thread priorities are honored and starvation doesn't occur.
>    
It isn't clear that thread priorities will do the job here. I have been 
burned before by things like priority inheritance chaining, and other 
ways that thread priorities can be elevated for potentially long periods 
of time.

Priority inheritance chaining goes like this:

Thread low locks mutex A, then mutex B

Thread high tries to lock mutex B, elevating low's priority to high's so 
that high can get the mutex quickly.

When thread low releases mutex B (letting high get it), the OS has 
trouble figuring out what low's priority should now be, and leaves it 
elevated until it releases all mutexes it still has (mutex A in this case).

Low is now running at a high priority, preventing thread medium from 
getting any CPU.


This scenario happened for me with vxWorks some time back, and is the 
reason I no longer do much work at all while I have a mutex locked. I am 
confident that it is a real problem to this day.

-- 
Graham St Jack