Priority Inversion in Monitors.

[gordon_hutchison@xxxxxxxxxx]

Hello All,

Hope you don't mind me pitching in, I implement the threading and monitors for
Java on AIX here in IBM and I thought I might be able to give an implementor's
perspective to
some small bit's and pieces, thus apologies for the lack of rigour in the
below....

>It's different with monitors.  If a thread is blocked trying to get a lock
>on a monitor, you probably can find out who has the lock (and raise its
>priority if necessary).

This is probably correct in that one must be careful not to try to get or try to
implement too many
higher level scheduling goals inside lower level mechanisms. However I thought
you
might be interested that in many implementations of Java
(forgetting for the moment complexities introduced via bi-model locking etc)
a monitor will very quickly map down to something like a mutex and condition
variable (in unix/POSIX terms).

Also many operating systems now have priority inheritance (or
ceilings/protection) in the
OS's mutex code.

Add these two together and you may get a little of what you suggest for free.
:-)

A similar thing came to mind on the discussion of the  unlock/waita ordering as
this
would tend to get implemented using an underlying 'atomic'
'add me to the listening queue and free the mutex'
operation such as pthread_cond_wait.

Leading on from this, I found the CSP models of threads/monitors fascinating
so thanks Peter and Jeremy.

I was wondering about the chain below, does it introduce 'extra'
internal choice that makes it more difficult to add new events to the
model?

waita.o.me -> release.o.me ->  waitb.o.me -> claim.o.me ->

e.g. what if Thread.interrupt was occurring between a release and a waitb, one
needs an external choice of the two.  Or is it cleaner as it is and
we would map notify/notifyAll and interrupt to waitb?

In my own mind notify does nothing but move a member from the
wait set (the choice being internal to the monitor according to the
Java spec)  to the entry set and notify moves the lot,  leaving the
wait set empty and the entry set the union of the two.

Off course,  none of this is from a 'hard' real time perspective and
off course apologies if the above seems 'old hat'.

Thanks for all the fascinating appends in the past and to Peter for the archive,

Gordon Hutchison
IBM Java Technology Centre,
IBM Hursley, UK.
Notes:   Gordon Hutchison/UK/IBM
Internet: gordon_hutchison@xxxxxxxxxx
Phone: (+44)/(0) 1962 815646 (Internal IBMUK-245646)