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
