A few comments in no particular order.
> Rule 1: No fusion may result in the possibility that more locks are
> simultaneously held at any given time than in the original code.
I understand the intent of rule #1, but I don't think its wording expresses
that intent. As written, this rule would prevent fusion if there were any
intervening statements between the locked regions: because the fusion would
be increase the number of locks that were held during the execution of the
intervening statements.
Real Time Java (RTJ) was mentioned in several messages. Do we need to
differentiate between those optimizations permitted at javac translation (to
byte-code), and those permitted at runtime (e.g., by hotspot)? Or does RTJ
have its own compiler, too?
Concerning loop unrolling: permitting some number of fused unrollings
woudn't bother me. In my experience, if a looping worker thread is sharing
a lock with a GUI event thread, then a yield or sleep (or even better: a
scheduler) is needed to prevent the worker from interfering with the
responsiveness of the GUI.
I think Doug's Thread.interrupted() example of when not to fuse is already
handled by the rules for synchs and volatiles. According to the JMM,
Thread.interrupted() has to employ either a volatile or a synch, right?
On the other hand, it might be a good idea if most of the Thread methods
were explicitly prevented from moving into a locked region:
Thread.interrupted()
Thread.yield()
Thread.sleep()
thread.start()
thread.join()
thread.interrupt()
thread.setPriority()
How about a new rule? For example:
Rule 3: Any method that can delay the current thread, change the priority
of any thread (esp. higher), or start a new thread cannot migrate into a
locked region.
-- Joe Bowbeer------------------------------- 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