> A read of a variable can yield any value permitted by the
> memory model. A "simple code inspection" involves reasoning
> which may or may not be valid within the context of the model.
In the proposed memory model (either SC- or M/P) a simple code
inspection gives you all will need most of the time:
- if there is an assignment in the code then that value is possible
from a read
- if there is no assignment of a given value, that value is not
possible from a read
Detailed analysis of the program in the context of the memory model
could reduce the size of the first set of possibilities - as could
analysis based on certain execution scenarios.
I expect these things to be clearly stated in the informal semantics
for the JMM ie the programmers model of the JMM.
Ignorance of synchronization and JMM issues in a multi-threaded
context can only be addressed through education. A programmer that
writes a secure but non-threadsafe class probably has a distored
notion of what "secure" means.
I'm not at all clear what you want/expect from the JMM in this
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:56 EDT