Re: JavaMemoryModel: Idiom for safe, unsynchronized reads

From: Doug Lea (
Date: Thu Jul 01 1999 - 07:39:38 EDT

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

* 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 But
  most of these kinds of tricks are unavailable at Java level, or when
  they are available, they introduce undesirable complexity and

Doug Lea, Computer Science Department, SUNY Oswego, Oswego, NY 13126 USA 315-341-2688 FAX:315-341-5424  
This is the JavaMemoryModel mailing list, managed by Majordomo 1.94.4.

To send a message to the list, email To send a request to the list, email and put your request in the body of the message (use the request "help" for help). For more information, visit

This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:14 EDT