JavaMemoryModel: A couple of things...

From: Bill Pugh (
Date: Sun Nov 21 1999 - 13:52:52 EST

   * Horrible synchronization idiom in _233_tmix
   * Number of synchronizations from multiple threads on the same object
   * Atomic reads/writes of elements of arrays of boolean/byte/char/short

One of the programs that was considered for the spec benchmarck and
rejected was _233_tmix, which is supposed to test a mix of thread

public class Go
    static boolean go;
    static { go = false; }

In the main thread:

    // Start a bunch of threads
    HashTest h = new HashTest((int)(HashTestSize*f));
    // and 10 more

    Go g = new Go();

In HashTest:

    Go g = new Go();
    public void run()

        while ( !g.go )

OK. First, there is the dumb idea to access a static variable through
a reference to an instance. Particularly when the different threads that
are trying to coordinate all have references to different instances.
This really should generate either a compiler warning or a compiler

Then, a _yield_ loop that is waiting to see a change in a
non-volatile variable.

Excuse me while I go be ill for a moment...


I'm back.

Jemery Mason added some instrumentation to our profiler to determine,
each time an object is locked, whether that object has every been
locked by a different thread previously.

I checked the synchronizations in tmix, and only one of the 11
benchmarks actually has two or more threads synchronizing on a shared

The mtrt benchmark (multithreaded ray tracing) doesn't perform any
useful synchronization worth mentioning. This is OK because it is one
of those massively parallel benchmarks.

The richards benchmark also doesn't appear to do any substantial
amount of synchronization on shared objects.

Atomic updates of array elements?

The way the mtrt benchmarks works without synchronization should be OK under any implementation scheme, because it uses an array of integers as the scene representation. But what if it used an array of bytes. In particular, if A is an array of bytes and if thread 1 is updating A[46] and thread 2 is simultaneously updating A[47], are those updates guaranteed to happen without interference?

My reading of the current spec is that yes, they are guaranteed to not interfere. But if updating A[i] is treated as a non-atomic: read of word containing A[i] update to reflect new value of A[i] write update to word containing A[i] then you can get interference.

On what machines are the standard instructions for partial word updates guaranteed to by atomic?

Bill ------------------------------- JavaMemoryModel mailing list -

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