> 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
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:42 EDT