At 1:05 AM -0400 7/30/03, victor.luchangco@sun.com wrote:
>
>
>Concerning the semantics, I think most of the disagreement is at a
>high level--should we make stronger or weaker guarantees, and why--and
>depends on our motivation for providing those guarantees. For
>example, I didn't realize that incorrectly synchronized code is always
>considered a mistake, so I wanted guarantees to help people write
>correct but incorrectly synchronized code. Now that I've been
>disabused of that idea, I don't see much motivation to provide any
>more guarantees than are necessary to ensure safety. Obviously,
>others, including you, disagree.
No, I do not disagree.
I just think that safety is a larger issue than type safety.
In particular, you need to worry that untrusted malicious code will
deliberately perform data races in an attempt to violate safety
checks.
In general, using synchronization at all entry points from untrusted
code isn't an option, due to problems with performance and deadlock.
So you need to program defensively against data races attacks by
untrusted code. This defensive programming will be a lot easier if
you know that even in the presence of malicious data race attacks by
untrusted code, execution will be causal.
Bill
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:48 EDT