As we work this down to the wire, I should also state that I very
much appreciate all the work Sarita has done on this problem. Jeremy
and I have found it very useful.
In my own opinion, writing reliable multithreaded software is one of
the harder tasks in software development right now. Debugging
misbehaving multithreaded software is even worse.
If you told me that in order to figure out the behavior of a
multithreaded application, I would have to consider executions
involving causal cycles and values that violate the happens-before
ordering, I think it would be time to find another line of work or
another programing language.
Software is hard. Cycles are cheap. Developers are expensive.
Reliability is vitally important. This is why people develop in type
safe languages like Java, even though there may sometimes be a small
performance penalty relative to unsafe languages.
If we push Sarita's model closer to CnC, but all the way to CnC, then
we have a system where people can almost always use consistency and
causality for reasoning about their program executions, except for
some corner case they will likely not understand.
So I propose that the core Java memory model should be consistency
and causality (or whatever name we use for those terms as we've been
using them). I think it will be more intuitive for programmers and
provide the guarantees programmers need. I know of no desirable
transformations that it disallows, and suspect that any
transformations it does forbid would be dubious or dangerous anyway.
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:47 EDT