Sadly, my thread selection rule is still wrong, and I've made it
unnecessarily complicated to boot. Its purpose is to avoid lost
notifications, but I was trying to avoid constraining the model. However,
since the actions are selected in no particular order, the thread that an
action chooses can be defined without that representing a constraint.
So the entire paragraph about notify actions is
If the action is a notify, then if possible a thread is removed from the
insideWait set. Otherwise the action is discarded.
For removal to be possible, the thread must have a group counter which is
less than or equal to the group counter of the notify action, and there
must be no other such thread with a higher group counter. If there is an
interrupt action in the acquireSet for the chosen thread, then the thread's
interrupted flag is set (but it will not throw InterruptedException). The
interrupt action is removed. The thread is granted the lock on the monitor,
and wakes up.
Hopefully, that is now correct.
My intent here is that all valid implementations should be equivalent to
processing the actions in the acquireSet in some implementation chosen
partial order. For example, an interrupt prioritizing policy would involve
processing interrupt actions before notify actions. A notify prioritizing
policy would process notify actions before interrupt actions. A non-barging
policy would process notify actions before wakeup actions. And so on.
The subject contains FWIW. It's probably too late to incorporate such a
radically changed model into the spec, even if people were willing to agree
that it is correct. Still, I thought it might be of interest.
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:54 EDT