This is in regard to several of the mails submitted recently in this list,
e.g., Victor wants to see intra-thread semantics,
and Sarita wants to see intuition to prohibited reads.
We believe that the true origin for Causality is in intra-thread semantics.
We thus have been working on a "software-oriented" approach that
attempts to remove the need for prohibited reads by spelling out
intra-thread semantics.
The result is a "CnC-compliant" definition w/o prohibited reads.
http://www.cs.technion.ac.il/~assaf/jmm/softnop.pdf
It is a preliminary draft, and is not uptodate with recent "slight
modifications"
that might have appeared in the last few days (hours?), but it gives you the
basic direction.
We will be happy to hear any comments.
---- Assaf
----- Original Message -----
From: "Sarita Adve" <sadve@cs.uiuc.edu>
To: <javamemorymodel@cs.umd.edu>
Sent: Tuesday, July 29, 2003 12:45 PM
Subject: Re: JavaMemoryModel: Why CnC
> 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.
>
> Sarita
>
> > -----Original Message-----
> > From: owner-javamemorymodel@cs.umd.edu
> > [mailto:owner-javamemorymodel@cs.umd.edu] On Behalf Of Bill Pugh
> > Sent: Tuesday, July 29, 2003 1:19 AM
> > To: javamemorymodel@cs.umd.edu
> > 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.
> >
> >
> > Bill
> > -------------------------------
> > JavaMemoryModel mailing list -
> > http://www.cs.umd.edu/~pugh/java/memoryModel
> >
>
>
> -------------------------------
> JavaMemoryModel mailing list -
http://www.cs.umd.edu/~pugh/java/memoryModel
>
-------------------------------
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