Alternative for volatiles with cheapest performance hit

Question

I want to implement the usual cooperative mechanism for canceling a thread. However the java memory model was only fixed in JDK5 while I'm in a pre-JDK5 environment. I understand, this means that doing something like this, as espoused in SCIP, will not be correct.

class Worker implements Runnable
{
    private volatile boolean _canceled;

    public void cancel() { _canceled = true; }

    public void run() {
        while( ! _canceled )
        {
            // do my shit
        }
    }
}

I'm thinking of using an AtomicBoolean to encapsulate the _canceled variable. Any other alternatives ? Thanks Stackoverflow.

Answer 1

I don't think AtomicBoolean was available before Java 5 either. What about synchronizing on a private Boolean field?

Answer 2

AtomicBoolean was also added in JDK5, so this isn't available unless you are using the backport. However, yes, the atomic class from the backport may be the best choice, as you know it was written by people who are versed in what works in each version of the JVM virtual machine spec.

Answer 3

The util.concurrent package by Doug Lea (the precursor to the java.util.concurrent stuff) might help.

Answer 4

If I understand the FAQ correctly, this is not a problem in the old memory model which allowed reordering of volatile fields. In their example, the old model would allow "x" to be either 0 or 42 based on the JVM. The rule of thumb is that reordering should always be a performance gain by the compiler/cpu, but not be visiable to the programmer. The old model broke that rule.

Your example should not suffer that visability problem and would work

Answer 5

IIRC, very old Sun JREs didn't implement volatile at all. Sensibly attempted, the old JMM allows volatiles to be used in this kind of way (about the only way they can be used). I understand Sun 1.4 JRE actually implements the 1.5 JMM, with any differences considered bugs.