>
> No, I think it is totally wrong to say that our model is that "the
> programmer must write correctly synchronized code", although Sarita
> has advocated this line of thought previously.
Yes, that was before Java's safety issues came up.
> * However, reality is that that programmers make mistakes
> and programs
> have errors. Incorrectly synchronized programs will have
> surprising
> and hard to understand behavior. However, the semantics
> will ensure
> a number of properties designed to increase the likelihood of
> safe and reliable behavior even in the presence of errors.
>
> For example, synchronization errors cannot lead to type
> errors. And
> I argue that synchronization errors should not lead to violations
> of consistency or causality.
Do we really believe that having CnC type causality is going to increase the
likelihood of reliable behavior on data races, if we think data races are
signs of bugs? It seems to me that if data races are bugs, we should work
hard to expose these bugs as much as we can, not conceal them with
guarantees of behavior that may make them work sometimes but probably break
at other times. Even if they break rarely, is that such a good idea - sounds
like we are doing our best to make this a really nasty bug. I am no expert
on this issue and am not going to push this aspect if there's resistance,
but I really am curious if people on this list agree with this sentiment.
On the other hand, I can easily understand a reasoning wanting
happens-before consistency (which by the way also needs some discussion to
handle write-write races right).
Sarita
-------------------------------
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