it's interesting to me to see this pop up here. let me throw a little gasoline on the fire.
while it is certainly true that ownership types, whether in the form of boyapati et al, flanagan and freund, or my work with strom and tarafdar, have some limitations/problems having to do with requirements for annotations and/or ability to express certain programs....
i've been watching for two years on this list as professors and ph.d. students in computer science go back and forth trying to understand the "memory model". if you need a ph.d. to understand the language semantics, then the language has a problem. languages are designed to be used by thousands or even millions of people. their meaning should be clearly statable. instead, the kinds of discussions i've watched going by on this list look like pilpul (*).
our experience in the field is that almost everyone programs java assuming that the memory is sequentially consistent. when it's not, they are truly surprised. i'm not just talking about the unwashed masses here. i'm talking about top-gun programmers, people with ph.d.'s, the whole gamut. and even when i explain to them why their programs are broken, it takes 3 or 4 times before they get it. it's not because they're dumb. it's because the "memory model" is so totally counter-intuitive that they just can't believe they really have to worry about such crap.
so while ownership types have open issues, i don't see that they have any more open issues than "flat memory with data races". they just don't happen to be in widespread (mis)use. but they will be a lot more reliable and scalable, and those advantages will only increase with memory latencies and aggressive processor designs.
david
(*) Pilpul (from the Hebrew "pilpel", "pepper") - a dialectical method of Talmudic study, consisting of examining all the arguments pro and con in order to find a logical argument for the application of the Law and at the same time to sharpen the wits of the student.
Source: Universal Jewish Encyclopedia inc., New-York, 1946, Vol. 8.
----- Original Message -----
From: <jmanson@cs.umd.edu>
To: "Joseph Bowbeer" <jozart@csi.com>
Cc: <javamemorymodel@ringding.cs.umd.edu>
Sent: Saturday, February 15, 2003 9:12 PM
Subject: Re: JavaMemoryModel: Re: Ownership Types for Safe Programming (was: Disallowing badly synchronized programs)
> > Can or does the JMM proposal leverage unique pointers? I don't remember
> > seeing it spelled out anywhere...
>
> No, and there is a very good reason why: you can avoid mutexes if the
> object has a unique pointer, but you can't avoid the memory semantics.
>
> If I recall correctly (I haven't looked at the paper since OOPSLA), from
> the perspective of the JMM, if you want unique pointers to work, the
> unique pointer has to be a volatile. You get the correct memory semantics
> and compilers can optimize away the barriers when the pointer is being
> used by a single thread. The optimizations might be an interesting thing
> to explore, actually...
>
> I wasn't necessarily going to reply to this thread, but I might as well
> put my two cents in on the notion of "unsynchronized access being the goto
> of the 90s". The notion of a data race free language is not a new one.
> It isn't even new for Java; David Bacon had a paper on his Guava system in
> OOPSLA 2000, and Flanagan and Freund had a paper on their ConcurrentJava
> in PLDI 2000. But there are lots of data race free concurrent languages
> out there.
>
> Chandra's system solves the problems a different way from these (with
> different flexibilities), and with ownership types (which is his
> dissertation research). It is interesting stuff.
>
> But as far as data race free languages being the way of the future - you
> have to come up with a way to express no data races in the language AND
> have the freedom to "roll your own synchronization" the way advanced
> concurrent programmers want to. There is too much you can't do with
> the current state of the art of these languages (double checked locking
> springs to mind for some perverse reason).
>
> This is, of course, another interesting thing to explore, but much harder:
> is there a way to allow complete freedom to roll your own synchronization
> and still prevent data races? It can't be done with static data race
> detection, because that is NP Hard. What we have now is a set of
> heuristics for detection, like "if there is a unique pointer, there is no
> data race".
>
> The question is, is there a middle ground that allows enough freedom for
> everyone to be happy with, but still disallows data races? I doubt you
> could cover all of the legitimate uses of volatile with static typing to
> the extent that other constructs cover all of the legitimate uses of goto
> (i.e., 999+ out of 1000 cases). Not that I'm not willing to be convinced
> otherwise.
>
> I personally had the thought that there might be some combination of
> static and dynamic techniques, as there is with memory management, but I
> haven't had the time to think this through properly.
>
> Jeremy
> -------------------------------
> 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:42 EDT