> From: Doug Lea [mailto:dl@cs.oswego.edu]
>
> > * At a point where a thread releases a lock (in the original
> > program), if another thread of equal or higher priority is
> waiting on
> > the lock, the other thread should be allowed to obtain (perhaps we
> > need to limited this to "compete for") the lock within a short
> > interval.
>
> Well, I hope not to be too cynical or pessimistic about this, but I
> am. Last I knew, there are JVM providers who absolutely will not
> accept such rules. (I believe that similar issues arose in POSIX.) I
> think the best we could hope for universal acceptance of is
> probablistic weak fairness. ("probablistic" because anything based in
> part on spinlocks will rely in part on effectively random hardware
> events.)
>
There's good reason to be concerned about making the rules too strict. Two
anecdotes:
1) I've seen a number of thread implementations (mostly non-Java) that have
MonitorExit hand off the lock to a waiting thread, but keep the original
thread running. This is arguably very fair, but often costs you one to two
orders of magnitude in performance on a uniprocessor due to lock convoying.
If you consider what happens if you have two threads frequently acquiring
and releasing a single global lock, you quickly see that you end up with one
context switch per lock acquisition, which is very bad. You would much
rather have each thread hold the lock for its entire time slice.
Based on one attempt to get a convoy-prone implementation fixed, there don't
appear to be too many solutions that don't trade away fairness or something
else.
2) I think it's fair to say that the general experience with strict thread
priorities in Xerox Cedar was negative. Eventually the underlying runtime
was changed to give each thread a time slice every once in a while, even if
it had low priority. Otherwise it was too hard to ensure that high priority
threads didn't end up waiting on low priority ones. (This can be fixed with
priority inheritance for MonitorEnter, but not for Object.wait(), since the
thread system doesn't know which thread is being waited for.) I suspect
that this experience doesn't apply to real-time systems, but it applies to
many other multithreaded systems.
Hans
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:29 EDT