At 2:10 PM -0700 7/16/99, Joshua Bloch wrote:
> Of course all of these suggestions horrify me. The Java philosophy has
>always been that it's the compiler's job to do the optimizing. Programmers
>should not have to think about this stuff. It would lead to all sorts of
>bugs.
I am still keeping an open mind about whether we should have a strong
or weak model. But the programmer has to take some responsibility.
For example, the spec could mandate that Java provide automatic
deadlock and data race detection. It would be expensive (at least,
the data race detection), but we could do it. But the spec doesn't
require it.
Going back to the question of what code breaks: There appear to be a
handful of cases with synchronized set / unsynchronized get methods
that should be fixed. Josh mentioned the collection view of maps, but
the entire Collection library is widely advertised as not being
thread safe. There are some improper uses of the unsafe single and
double check idioms, but they could just be considered bugs.
Using static tools to detect potential data races and runtime tools
that detect exhibited data races should probably be part of any major
multithreaded software project.
When it comes time for a decision to be eventually made about what to
make the Java memory model, we will need to put together the case for
why Java needs a strong memory model (as well as the case for why
Java should have a weak memory model). Although you can make the
argument on religious grounds, I would like a stronger factual basis
than that the fact that there are 3 dozen data race bugs in the JDK.
Which isn't to say that the basis isn't there. Just that it needs to
be documented better.
Part of the question is to what extent are we willing to say: "A data
race is an _error_. If you have an error, we guarantee safety, but
not much more".
For example, if you have a class that guards a protected resource,
all of your fields should be private and all of your methods
synchronized (to guard against unexpected results due to data races).
In this case, others will not be able to use a weak memory model to
attack your code. So it isn't clear that a weak memory model isn't
compatible with safety.
Bill
-------------------------------
This is the JavaMemoryModel mailing list, managed by Majordomo 1.94.4.
To send a message to the list, email JavaMemoryModel@cs.umd.edu
To send a request to the list, email majordomo@cs.umd.edu and put
your request in the body of the message (use the request "help" for help).
For more information, visit http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:17 EDT