Bill and Jeremy,
Can you give us all a *full* intuitive description of consistency+causality
please? We don't have one yet that includes the effect of prohibited reads.
Or are you going to argue that you don't need to have prohibited reads in
your intuitive description? I hope that is not the case.
I cannot yet take SC- all the way down to CnC because I haven't yet got my
head around prohibited reads (I admit I haven't spent as much time on them
as the rest of CnC, but I have spent a lot time). That is the only aspect of
this whole puzzle that still bothers me.
> -----Original Message-----
> From: email@example.com
> [mailto:firstname.lastname@example.org] On Behalf Of Bill Pugh
> Sent: Tuesday, July 29, 2003 1:19 AM
> To: email@example.com
> Subject: JavaMemoryModel: Why CnC
> 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 -
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