At some point it would be useful to put together a definitive list of
issues and concerns surrounding initialization, but for now, here is
some more fodder on the pro-initialization-guarantee side. (Sorry if
this sounds like lobbying. I'm merely trying to recap and update
concerns expressed in previous discussions with various people on this.)
* At the hardware or JVM level, accommodations for initialization might
appear to require exceptions to other rules. But from a
programmer's point of view it is completely the opposite. The
motivation for linking memory rules and locking rules is that if a
programmer preserves invariants and avoids semantic conflicts via
normal locking practices, then the memory visibility and ordering
issues will take care of themselves. (Thus, programmers need a deep
understanding of memory model only if they do not employ normal safe
locking practices.) In the case of normal constructor practices,
there are conceptually no semantic conflicts, so no motivation to
use locks.
* Most people who program in C using pthreads on machines like alphas
need to adopt a different outlook and set of rules: Use
synchronization for all operations on all potentially shared
objects, whether or not they could encounter semantic conflicts.
This rule is attractively simple, but unattractively introduces yet
more context dependence to OO class design, adding more cases where
multiple versions of the same functionality should sometimes be
implemented in different ways depending on whether instances of a
class could ever be shared, as opposed to whether they could
encounter conflicts if shared. Normal java design practices differ
from those used in pthreads etc in that objects themselves, not the
code that uses them, are generally responsible for ensuring their
own safety and integrity. Most OO programmers think this is a Good
Thing.
* If the mistakes (-:) surrounding initialization in JLS are not
fixed, then practically all production concurrent Java systems (of
which by now there are many) would contain many unanticipated safety
violations. People routinely rely on immutability of String, Integer,
Color, etc.
* Conversely, if String, etc and all usages of them in all contexts
that cannot preclude multithreaded access were somehow changed to
employ locks, this would impact performance. It is an empirical
question whether using full locks for String etc would be faster or
slower than using barriers for all constructors and accesses.
Although it is not an empirical question about which way would be
faster on machines that don't require barriers.
* I've been concentrating on the case of initialization of immutables
mainly because in just about all other contexts, people will need to
use locks anyway, so the issue has less impact. But it seems to me
that the underlying problem is that none of memory models that I
know about consider `publication dependency', to give a name to
properties surrounding ...
a.x = 1; // initialize
b = a; // publish
... as a constraint on equal footing as value and control dependencies.
Does anyone know of any work on memory models, or maybe dataflow,
that addresses this?
* It seems impossible to write programs without relying on some property
of initial values. Omitting initialization guarantees might just
barely be tolerable to JVM developers because they can still supply
their own by zero-filling pages and handling traps etc. (Or for some
more exotic options, see the Greenwald and Cheriton paper `The
Synergy Between Non-blocking Synchronization and Operating System
Structure' at http://www-dsg.stanford.edu/Publications.html.) But
most of these kinds of tricks are unavailable at Java level, or when
they are available, they introduce undesirable complexity and
error-proneness.
-- Doug Lea, Computer Science Department, SUNY Oswego, Oswego, NY 13126 USA dl@cs.oswego.edu 315-341-2688 FAX:315-341-5424 http://gee.cs.oswego.edu/ ------------------------------- This is the JavaMemoryModel mailing list, managed by Majordomo 1.94.4.To send a message to the list, email JavaMemoryModel@cs.umd.edu To send a request to the list, email majordomo@cs.umd.edu and put your request in the body of the message (use the request "help" for help). For more information, visit http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:14 EDT