Re: JavaMemoryModel: Idiom for safe, unsynchronized reads

From: Joseph Bowbeer (
Date: Thu Jul 01 1999 - 15:22:32 EDT

I'd much rather read email from all of you than have you all read mine, but
I can't let this pass without piping in.

----- Original Message -----
From: Doug Lea <>
To: <>
Sent: Thursday, July 01, 1999 4:39 AM
Subject: Re: JavaMemoryModel: Idiom for safe, unsynchronized reads

>*Most people who program in C using pthreads on machines like
> alphas need to adopt a different outlook and set of rules . . .
> This rule is attractively simple, but unattractively introduces yet
> more context dependence to OO class design . . .
> . . . 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.

True, Java design practices lean more heavily on placing the responsibility
for thread-safety on the object, and it may be a good thing from an OO point
of view, but I wonder about the strength of this argument.

1. It's not happening in practice.

The Beans spec (reusable components) says that Beans should be thread-safe,
but most beans are generated by IDEs and none of the IDEs (I've seen) are
writing thread-safe code. To pick one recurring example: the sample code in
the Beans spec for property-change notification and vetoing is not
thread-safe. The IDEs that generate the code don't improve on the spec, and
most people hand-coding their own beans aren't doing any better. (Because of
the difficulty and tedium involved, I think that designing-in thread-safety
is a good thing *not* to be doing if it can be avoided.)

2. It places too much burden on the class designer. Either way you go, the
context dependence creeps in. If the object is responsible, the context
dependence moves inside the object implementation, where it doesn't belong.

Consider this simple class with a single int property:

    class Foo {
        private int value;
        public int getValue() {
            return value;
        public setValue(int value) {
            this.value = value;

Should the accessors be synchronized (for transmission)? Depends on the

> * 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.

Once initialization is fixed, other bugs surrounding visibility - in
production code and in the JDK - would surface.

Joe Bowbeer

------------------------------- 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