This discussion seems to have gone quiet.
I would really like to see VMs implement the semantics as originally
defined in the API, particularly as the alternatives seem, without
exception, ugly. However, I know that views have been expressed as to the
practicality of this.
After some thought, I've come up with the files in the directory
http://members.optushome.com.au/sylviae/thread. Of these, the main one of
interest is ObjectEx.java. The intent is to use Java to describe an
algorithm that allows Java's original thread semantics to be achieved on
top of an operating system that provides only wait/notify with spurious
wakeups and a mutual exclusion primitive. The wait/notify does not need a
notify all operation, nor does it need to be interruptible. In this regard,
I note that Posix pthread_cond_wait does not necessarily return when the
thread receives a signal.
Note that the Monitor class is just a simulation of the underlying Java
monitor so that my code would have access to the unlock and lock methods.
The ThreadEx class delegates its methods to static methods in ObjectEx,
because I think that it makes ObjectEx easier to low. The various ....Ex()
methods correspond to the similarly named methods of Object and Thread
without the Ex suffix.
The first question, of course, is whether the algorithm is correct, and, if
not, whether it can be repaired.
If it is, then one significant issue is that it uses a single system-wide
mutual exclusion lock. This was not due to laziness on my part, but seems
to be inherent in the semantics of notify() and interrupt(). The notify()
method starts with an wait set, and having chosen a thread, needs to wake
it up. By contrast, the interrupt() method starts with a thread, and then
needs to remove it from whichever wait set it's in, if any. When I tried to
write this stuff using a lock for each object, I quickly found that I had
to lock the same two objects in each method, but in the opposite order. The
potential deadlock can be avoided by means of a loop, but there seemed no
guarantee that interruptEx() would ever complete.
At the very least, perhaps this will encourage some discussion that
clarifies the distinction between what is unreasonably complex, and what is
merely inconvenient, or deemed unacceptably inefficient.
Sylvia.
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:46 EDT