Doubt on avoiding liveness failure - discussed in Effective Java

I am refering to page 261 - 262 of Joshua Bloch Effective Java

// Properly synchronized cooperative thread termination
public class StopThread {
    private static boolean stopRequested;

    private static synchronized void requestStop() {
        stopRequested = true;
    }

    private static synchronized boolean stopRequested() {
        return stopRequested;
    }

    public static void main(String[] args) throws InterruptedException {
        Thread backgroundThread = new Thread(new Runnable() {
            public void run() {
                int i = 0;
                while (!stopRequested())
                    i++;
            }
        });
        backgroundThread.start();
        TimeUnit.SECONDS.sleep(1);
        requestStop();
    }
}

Note that both the write method (requestStop) and the read method (stop- Requested) are synchronized. It is not sufficient to synchronize only the write method! In fact, synchronization has no effect unless both read and write operations are synchronized.

Joshua's example is synchronized on this. However My doubt is that, must synchronized be acted on the same object? Say, if I change the code to

    private static void requestStop() {
        synchronized(other_static_final_object_monitor) {
            stopRequested = true;
        }
    }

    private static synchronized boolean stopRequested() {
        return stopRequested;
    }

will this still able to avoid liveness failure?

That's is, we know grabbing monitor for a same object during read/write can avoid liveness failure (According开发者_JS百科 to Joshua Bloch's example). But how about grabbing monitor for different object during read/write?

I don't believe it's guaranteed, although I wouldn't be surprised if it actually was okay in all existing implementations. The Java Language Specification, section 17.4.4 states this:

An unlock action on monitor m synchronizes-with all subsequent lock actions on m (where subsequent is defined according to the synchronization order).

I believe that all the safety of reading/writing shared variables within locks stems from that bullet point in the spec - and that only specifies anything about a lock and an unlock action on a single monitor.

EDIT: Even if this did work for a single variable, you wouldn't want to use it for multiple variables. If you update multiple variables while holding a monitor and only read from them when holding a monitor, you can ensure that you always read a consistent set of data: nothing's going to write to variable Y before you've read that but after you've read variable X. If you use different monitors for reading and writing, that consistency goes away: the values could be changed at any time while you're reading them.

Possibly, but there are no guarantees and it could be highly platform dependant. In your case there is no real test for liveliness so if the value is a few milli-seconds late your application will appear to work correctly anyway. The application will stop eventually without any synchronized and you may not see then difference.

The problem with memory consistency errors is I have seen examples where something can be updated correctly in a test 1 billion times and then fail when there is a different program running on the system. This is why guaranteed behaviour is more interesting.

According to the The Java Language Specification,

"We say that a read r of a variable v is allowed to observe a write w to v if, in the happens-before partial order of the execution trace:

• r is not ordered before w (i.e., it is not the case that hb(r, w), and
• there is no intervening write w' to v (i.e., no write w' to v such that hb(w, w') and hb(w', r).

Informally, a read r is allowed to see the result of a write w if there is no happens-before ordering to prevent that read."

This means that unless there is some explicit synchronization action that causes multiple threads to interleave their actions in some predictable way (i.e. there's a good happens-before relationship defined on their actions), then a thread is allowed to see pretty much any value of a variable at any point where it was written to.

If you synchronize on multiple different objects, there is no happens-before relationship connecting the reader and the writer. This means that the reading thread can keep seeing whatever value it wants for the stopRequested variable, which could either be the first value forever, or the new value as soon as its updated, or something delightfully in-between the two.

Theoretically it's wrong. Per lang spec v3, the background thread may not see the update.

Practically it'll work. VM just can't be that smart to optimize to such a degree. (In older version of Java, which has threading spec worded differently, it is possible that your suggestion is correct even in theory.)

In any case, don't do it.

If you use a different monitor, there is no synchronization. No other code is requesting the monitor of this or other_static_final_object_monitor.

Using a static object to synchronize is only useful, if you want to synchronize across classes and within methods.

Also, NEVER use a String as a lock/monitor. Always use something like this:

 static final Object LOCK = new Object();