> From my perspective, the main reason the simpler model is
> not acceptable is that developers can quite innocently write a class
that
> is not intended to be used in a multi-threaded way, but which
exposes
> security holes when malicious code invokes the methods from multiple
threads.
Right. It's not enough to say "don't write programs with races", the
JMM also has to provide for the basic "security" of the Java
platform - which is where the "not out-of-thin-air" rule comes in.
That given, it's up to individual API writers to make sure their code
doesn't break their own "local" security. To do that they have to
think about how their code might be susceptible to a multi-threaded
attack. The simplest solution would be to use some form of
synchronization - either locks, or volatiles. But the basic "rule"
that tells the programmer they may have a problem is quite simple: in
the absence of synchronization a variable read may return any value
that it has ever held in the program. That's stating it worse than it
is, because for any given read the memory model may reduce the set of
possible return values.
I think this is a simple rule that can be programmed to without having
to get into the details of the memory model. It's my understanding
that both SC- and M/P support this rule.
David Holmes
-------------------------------
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