OK, all of the issues aren't really memory model issues, but due to
the overlap with memory model issues, I'll post some thoughts here
before sending them in.
I've proposed that volatile should act as a synchronization access:
reads of a volatile act as an acquire (forcing a reload from main
memory) and writes to a volatile act as a release (forcing a flush of
writes to main memory). For RawMemoryAccess in RTJava, it isn't clear
if that is needed. However, for some of the cases where it is used
(e.g., memory mapped I/O), it needs to be have the semantics:
* Always goes directly to memory
* Is sequentially consistent with respect to other RawMemoryAccesses
Therefore, to avoid coupling which could cause a problem when we try
to decide want we want for volatile in non-real-time Java, I suggest
we _not_ define RawMemoryAccess in terms of volatile. Instead, we
should just recommend the above two bullets.
Secondly, the libraries should all specify the level of thread safety
they support. This isn't a standard part of the API; it isn't
determined by whether or not the implementation of the methods are
declared to be synchronized. This would address the issue of whether
the WaitFreeQueue accesses are correctly synchronized.
Thirdly, the spec defines AsynchronousInterruptedException. There are a lot of
clumsy things about them, but here is one specific issue: Are they
precise? In other words, if an AsynchronousInterruptedException
occurs, is it the case that it must be as though all of the bytecodes
up to a specific point in execution were executed, and none of the
ones after that were executed? This would pretty much prohibit any
reordering of memory access operations within methods where AIE's can
occur. In methods that catch AIE's, it might even prohibit some
reorderings of updates to local variables.
Bill
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:24 EDT