Re: Serious concurrency problems on fast systems
On Wed, 2 Jun 2010, Patricia Shanahan wrote:
Mike Amling wrote:
Arne Vajh?j wrote:
-XXdonotkickthreadoffcpuifitisabadtimeforperformance does not exist.
No, but someday there could be an option to let a Thread synchronized on
a monitor for which another Thread is waiting run a little longer, in hope
that it will desynchronize.
If the kernel developers wanted to do something to solve priority
inversion, why not implement priority inheritance, a long studied
technique?
I don't understand the details, but there are people who are not keen on
it. I think because (a) it can be slow and (b) it can let developers get
away with writing bad code, although the latter sounds like a bullshit
reason to me. Anyway, Linux has priority-inheriting mutexes in the
real-time edition, and as the infrastructure underlying futexes in recent
normal versions. If java uses futexes on linux, then it already has
priority inheritance.
However, priority inheritance, UIVMM, makes no difference at all if the
threads involved are all of the same priority. If a priority-N thread
blocks on a lock held by a priority-N thread, there is no boost to apply,
and nothing in priority inheritance that will get the first thread off the
lock any quicker.
Something that might help is directed yields: if a thread blocks on a lock
with some time left in its timeslice, it donates it to the thread holding
the lock (which then uses all of it, or runs until it releases the lock,
or something). I've come across the idea in IPC mechanisms: process A runs
an IPC primitive which sends a message to process B and waits for a reply;
since A is blocked, it might as well give its time to B in the hope that B
will reply sooner. It's a fairly straightforward extension to apply that
to locking.
tom
--
Like Kurosawa i make mad films; okay, i don't make films, but if i did
they'd have a samurai.