[651] in java-interest
Re: Language issue: thread synchronisation
daemon@ATHENA.MIT.EDU (Mathew Lodge)
Tue Jul 11 20:19:48 1995
Date: Tue, 11 Jul 1995 18:08:55 -0600
From: lodge@houston.omnes.net (Mathew Lodge)
To: java-interest@java.sun.com
Chris Warth wrote:
>Anyway, to answer your question, monitors are not just for mutual
>exclusion, they also include condition variables and so can be used for
>synchronization as well.
>
>Synchronizing two threads is just a slight variation on serializing
>access to an object. All you have to do is consider one of the threads
>to be the object whose access you want to serialize.
OK, good stuff! But... you made me think of another question :-)
If there is more than one thread waiting on a synchronised object, which
one acquires the monitor when the current thread releases the monitor? Is
it the first one that got there, or is it done by priority, or just
non-deterministic?
And is there anything in the spec for the runtime to avoid priority inversion?
[Priority inversion is where a high priority thread can't run because a
resource it wants (e.g. a synchronised object) is held by a lower priority
thread. This is a major flaw for any language claiming to be "real time".
You get around priority inversion by having the runtime temporarily bump up
the priority of the thread holding the monitor to that of the highest
priority waiting thread. So, to avoid priority inversion you need: (1)
Dynamic priorities (which Java has) and (2) prioritised waiting on
monitors]
Thanks again,
Mathew
|Mathew Lodge: lodge@houston.omnes.net |5599 San Felipe, 4th Floor|
|Internet Specialist, Omnes -- A |Houston, Texas 77056, USA |
|Schlumberger/Cable & Wireless company for|Phone: +1 713 513 3237 |
|Global Communications Solutions |Fax: +1 713 513 3126 |
-
Note to Sun employees: this is an EXTERNAL mailing list!
Info: send 'help' to java-interest-request@java.sun.com
