An important point to keep in mind is that we shouldn't be defining a
memory model that we would like to program to. Rather, we have to define a
memory model for the millions of Java programmers who are rather
unsophisticated when it comes to concurrency.
I can imagine two approaches to that goal.
(a) One approach is to devise a model that will allow as many as possible
of their naive notions about concurrent programming to work, while still
being possible to implement the model on SMP's with weak memory models with
reasonable efficiency.
(b) The second approach is to draw a very simple, square box, and say: "You
must program in the box". We can completely describe the box in no more
than a few pages, and provide them with static and dynamic tools for
testing if they are in the box. One simple box is "Use must use
synchronization or volatile variables to communicate between threads".
The problem with (a) is that the acceptable idioms will have almost a
fractal-like boundary. It will be very hard to specify the boundary, and
very, very few people will be able to distinguish an idiom that guaranteed
to work and an idiom that isn't. It will be difficult or impossible to use
testing to find uses of broken idioms, because many of them will only arise
on SMP's weak memory models, and then only sporadically. Because of the
complexity of the boundary, it is unlikely that there will be any static or
dynamic tools that will be able to test whether you code uses only legal
idioms. It will be difficult to write compilers and/or other program
transformation tools and ensure that they do not move a program across the
boundary.
The problem with (b) is that lots of existing code is outside any simple
box we might construct. We could probably provide some "outside the box"
guarantees for safety purposes (e.g., Strings are immutable).
Bill
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:21 EDT