Lecture Notes for Concurrent Programming

3 July 2003 - The JVM System Architecture

Outline

• Java Storage

• Data Atomicity

• Change Visibility

• Execution Ordering

• Volatile Class Fields

System Architectures

• Understanding the system architecture is crucial to writing correct and effective concurrent computations.

• The system architecture determines the

  • Atomicity characteristics of the data.

  • The way on which data are transfered from place to place.

  • How instructions are executed and their atomicity.

• So it is with the Java Virtual Machine (JVM) system architecture.

  • Many JVM architectural features are wrong, poorly specified, and implemented incorrectly.

  • Unfortunately, many of these problems involve storage management.

The JVM System Architecture

• This is a multiprocessor architecture

Variables

• Threads read and write storage locations corresponding to variables.

• A variable is a class or instance variable, or an array element.

  • These are data which are, or can be, globally accessable.

• Local variables can be ignored in this discussion.

  • Local variables can only be accessed by the containing thead.

    void f(Object obj)
      int i
      i = ...
    

  • Method parameters can be ignored fror the same reason.

Thread Variable Access

• All thread variable accesses are to and from the local cache.
  

• The local cache is a lazy write-back cache.

  • Changes to the local cache are not automatically written through to global storage.

  • This behavior leads to cache consistency problems.

• The local cache need not contain all an instance's variables.

  • The variables accessed will be cache resident.

  • Prefetching is allowed, though.

Global and Local Storage

• A local cache miss forces a load from global storage.
  

• What about flushing the local cache back to gobal storage?

  • Write-backs are forced with synchronized blocks.

Synchronized Blocks and Cache State

• Acquiring a lock on a class instance invalidates the thread's local cache.

  • The whole cache is invalidated, not just the entries associated with the instance being locked.

  • Read-accessed variables have to be re-read from global storage.

  • Modified variables are flushed back to global storage.

    • Modifying shared variables outside a synchronized block is bad programming.

• Releasing a lock on a class instance flushes all modified variables back to global storage.

  • All modified variables are flushed, not just the ones associated with the locked instance.

  • The unlock doesn't complete until all modified variables are written into global storage.

Data Atomicity

• Read-write atomicity.

  All bits in a datum belong to the same value.

• All basic types except long and double are read-write atomic.

  • Object references included.

  • long and double need not be read-write atomic.

• volatile longs and doubles are read-write atomic.

• Classes and their instances are not atomic.

Change Visibility

• When can a thread-local change be seen by other threads?

• Releasing an object lock flushes the thread's changes back to global storage.

• Acquiring an object lock loads the object data into the thread.

  • Notice the two-step process: writer unlocks and reader locks.

  • synchronize also indicates low-level storage updates.

  • Flushing and loading are not atomic.

• Volatile fields are directly read from and written to global storage.

  • The local cache isn't involved with volatile fields.

• First time reads always return a valid value.

  • Either the initial value or some written value.

• Thread termination flushes local changes to global storage.

• It may take arbitrary long for changes to reach global storage.

Execution Ordering

• When does i = j = 0?
  

• Within a thread, instructions are executed in sequential order.

  • "As-if" sequential order, in the absence of side-effects.

  • Optimizing re-arrangements.

• One thread may observe arbitray execution orders in an other thread.

  • The sequence of synchronized and volatile references is preserved.

• Within-thread order is useless when interference is present.

• Compilers can re-arrange statements without effecting sequential execution.
  

Volatile Class Fields

• Read-write access to a volatile class field always accesses global storage.

  • Separated read-write accesses may be interfered with.

• Only tagged fields are volatile; untagged fields are cached.

• Volatile fields are good for one-to-many communication.

  • One thread writes a volatile field.

  • The other threads read it.

• The volatile keyword is not transitive.
  

  • A volatile array does not have volatile elements.

Volatile vs. synchronized

• Volatile fields are no cheaper than synchronization.

  // Using volatile
  
     class Count { volatile int count = 0; }
  
     public void f(Count c) { c.count }
  
  // Using synchronized
  
     class Count { int count = 0; }
  
     public void f(Count c)
       synchronized(c) { c.count }
  

• If accessed infrequently, they can be no more expensive either.

• Avoiding interference still requires explicit synchronization.

  void good_add1(Count c) 
    synchronized(c) { c.count++ }
  
  void bad_add1(Count c) 
    c.count++
  

Points to Remember

• Multiple threads lead to data-consistency problems.

  • Copies of data being changed.

• Java specifies weak data-consistency support.

  • Although JVM implementations are usually stronger than specified.

• long and double may not be atomic; other base types are.

  • Classes as a whole are default non-atomic (unsynchronized).

• Volatile data types and class fields support atomic access.

  • Usually exploited in special cases.

• Any significant sharing among threads requires synchronization.

  • Beware unsyncnronized threads; interference is the rule.

This page last modified on 3 July 2003.