TDPL, shared data, and Phobos

[Sean Kelly]

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.