----- Original Message -----
From: Bill Pugh <pugh@cs.umd.edu>
Sent: Saturday, July 17, 1999 7:54 AM
Subject: proposal for semantics & implementationonrelaxed memory model
machines
> At 2:10 PM -0700 7/16/99, Joshua Bloch wrote:
> > Of course all of these suggestions horrify me . . .
>
> 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.
>
I think the JDK examples are a strong basis. A naive programmer looking at
the "author" lines in these source files would figure these folks knew what
they were doing. I've found lots of bugs in books, articles, and online code
(show me a 'synchronized' and I can probably find a bug related to it), but
I think the JDK bugs are the most convincing. The bugs cascade down from
there, flowing through Java books and articles, and finally settling in the
entire Java code base.
The JDK examples also represent the hurdle that will have to be leaped
before *any* code has a chance to work reliably on a relaxed memory system.
Realize, too, that every applet is multi-threaded. The constructor / init /
start / stop methods are called in a different thread than the paint method
and the event handlers. It's hard to avoid these considerations in Java.
For these reasons, by the way, I think that any compromise of safety or
security should place the burden on the optimizers.
> 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.
>
I strongly suggest bringing the security experts into this discussion (Li
Gong? David Hopwood?). I'm not convinced that secure classes don't need to
worry about the initialization of other resources.
I've been impressed with how carefully the security breakers and
fixer-uppers have scoured the many exposed surfaces of Java, but I think
they're overlooking an important region: multi-threaded attack.
-- Joe Bowbeer------------------------------- 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