>Here is a thought! why not let loose those programs that are racy.
>Bad idea for Sun, since we sacrifice portability. What the heck,
>since the problem is already racy, multiple run on the same
>platform will yield different results!
>
>Sreedhar
This is, to a large extent, what we have been talking about:
What, if any, guarantees do we want to make for
programs that have data races?
Clearly, we don't want to give up our usual safety guarantees. We can't
allow a program to violate type safety just because it has a data race. For
example, this mandates the fact that reads and writes of references must be
atomic.
As someone trying to write code that controls a sensitive resource,
you need to worry about whether an attacker could use data races to
attack your code/resource.
For example, in java.lang.Classloader, there is a boolean flag "initialized"
which is checked to make sure the classloader is initialized. But if you look
at the existing memory model, you will see that it doesn't work. It is quite
possible that another thread would see the true value written to
initialized at the end of the constructor, but see default values for
all of the other fields. If we guanranteed initialization safety, we
wouldn't even need the boolean field.
So we figure out what safety guarantees we want to provide. And then say other
than that, you will get very surprising results if you have a data race.
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:13 EDT