Question

I read this stackoverflow topic, which conclusion seems to be that an empty synchronized block can always be avoided with a nicer solution. The topic also has some unclear parts to me, which I’ll integrate to my below post.

Assume we have a class like this:

public class MyThreadClass extends Thread {
  private final OtherComponent mOtherComponent;
  private final Object mLock = new Object();
  private MyHandler mHandler;

  public MyCustomThread(OtherComponent otherComponent) {
      mOtherComponent = otherComponent;      

  public void run() {

      mHandler = new Handler() {...}

      // Other init operations

      mOtherComponent.onMyCustomThreadInitialized();

      // ... other operations (Looper.loop(), actually)
  }

  public void sendMessageWithHandler(int what, int arg) {
       synchronized (mLock) {}
       Message msg = mHandler.obtainMessage(what);
       msg.arg1 = arg;
       mHandler.sendMessage(msg);
  }

  public void useHandlerInAnotherWay(...) {
       synchronized (mLock) {
            // useful code that needs actual mutual exclusion
       }
       mHandler.sendMessage(...);
  }
}

The relevant part of my application works in the following way:

1. The MyThreadClass thread is created and started.
2. As an indirect consequence of mOtherComponent.onMyCustomThreadInitialized(), another part of my application will start spawning other threads. (Note that they aren’t started synchronously from this call, that is why I say it’s indirect consequence. The only point is, mHandler has been initialized by the time these other threads are started)
3. Each of the other threads will call sendMessageWithHandler(...) exactly once
4. Yet again other threads (i.e. not the threads mentioned above) call useHandlerInAnotherWay(...), this can happen at any time (after mOtherComponent.onMyCustomThreadInitialized(), of course).

My questions:

1. If I’m correct, up-to-date data visibility must be guaranteed when mHandler is accessed from other threads than myThreadClass, because it is not a final field. I don’t want to make it volatile either, because except for these few sendMessageWithHandler(..) calls, mHandler is not used from other threads without synchronization (I don’t want the volatile overhead to be present unnecessarily where it’s needless). In other words, when mHandler is accessed from those yet other threads via useHandlerInAnotherWay(), the synchronized there with the “useful code” (i.e. code that actually needs to be a subject of mutual exclusion) also guarantees that the caller thread sees mHandler correctly. In sendMessageWithHandler(..), however, the code does not require mutual exclusion, so I decided to put an empty synchronized block to the beginning of sendMessageWithHandler(...). Is this correct? Is there a nicer solution to my problem?

2. The other stackoverflow thread I linked to has the following answer (it’s not the accepted one, but was upvoted multiple times):

   It used to be the case that the specification implied certain memory
   barrier operations occurred. However, the spec has now changed and the
   original spec was never implemented correctly. It may be used to wait
   for another thread to release the lock, but coordinating that the
   other thread has already acquired the lock would be tricky.

   Does this mean that the empty synchronized does not offer the memory barrier functionality anymore? If I check the Java docs online about synchronized, they mention that ALL memory is updated due to it (i.e. thread copies are updated from “main memory” at monitor enter, and “main memory” is updated from thread copies at monitor exit). But they don’t mention anything about empty synchronized blocks, so this is unclear to me.

Answer 1

You probably don’t need any synchronization.

(thread 1)          (thread 2)

write
  |
start thread 2
                 \
                    ...
                     |
                    read  

read is guaranteed to see write.

---

The semantics of synchronized is strictly enforced, even if it’s an empty block.