title: Why does my synchronized code block seem to ignore another, waiting synchronized block on the same object?
body: <p>I am rather puzzled about the behavior of synchronized code blocks in Java. There is one behavior I'm observing that I just don't get. Consider the following code (I'm going to reuse the code example from another question I asked <a href="https://stackoverflow.com/questions/21099413/why-are-two-synchronized-blocks-acting-like-ive-provided-different-monitor-obje">here</a>, as the structure is the same):</p>
  
  <pre><code>class Outer {
      private Object lock;
      private Foo foo;        
  
      public Outer() {
          lock = new Object();
  
          // The thread is actually started in an Android callback method,
          // but I'll start it here as a demonstration
          InnerThread thread = new InnerThread(lock);
          thread.setRunning(true);
          thread.start();
      }
  
      private void modifyFoo() {
          synchronized(lock) {
              Log.d("outer", "outer method");
              foo.bar();    // Has some effect on foo
          }
      }
  
      private class InnerThread extends Thread {
  
          private volatile boolean running = false;
          private Object lock;
  
          public InnerThread(Object lock) {
              this.lock = lock;
          }
  
          private void setRunning(boolean running) {
              this.running = running;
          }
  
          @Override
          public void run() {
              while(running) {
                  // There is some timer management code here.
                  // It executes on the order of microseconds.
  
                  synchronized(lock) {
                      Log.d("thread", "loop");
                      foo.blah();    // Modifies foo
                      // Imagine some time intensive (milliseconds)
                      // drawing method calls here
                  }
              }
          }
  
      }
  }
  </code></pre>
  
  <p>This approach may appear convoluted; just be aware that I adapted this from one of the Android sample applications, and this question isn't about redesigning the structure of my code, unless that is necessary to fix the issue. Just bear in mind that the <code>while</code> loop in the thread is a drawing loop, and that my game logic sometimes comes in and calls the <code>modifyFoo</code> method (Android SDK users may recognize this as a modification to the LunarLander example). The call to modifyFoo looks like this:</p>
  
  <pre><code>Log.d("activity", "calling modifyFoo");
  modifyFoo();
  </code></pre>
  
  <p>The unexpected behavior is shown in the log output when I call the method. I expect something like this:</p>
  
  <pre><code>thread: loop
  thread: loop
  thread: loop &lt; `modifyFoo` method called during this loop iteration
  activity: called modifyFoo
  outer: outer method
  thread: loop
  thread: loop
  </code></pre>
  
  <p>But I see results more like this (<strong>EDIT: Copied actual log with timestamps)</strong>:</p>
  
  <pre><code>01-23 04:34:28.303: D/thread(399): loop
  01-23 04:34:28.335: D/thread(399): loop
  01-23 04:34:28.350: D/activity(399): calling modifyFoo
  01-23 04:34:28.366: D/thread(399): loop
  01-23 04:34:28.381: D/thread(399): loop
  01-23 04:34:28.413: D/thread(399): loop
  01-23 04:34:28.428: D/outer(399): outer method
  01-23 04:34:28.436: D/thread(399): loop
  01-23 04:34:28.460: D/thread(399): loop
  </code></pre>
  
  <p>Note that adding additional log statements at the beginning and end of the synchronized block in the loop confirms that the <code>modifyFoo</code> method is being called while this block is executing.</p>
  
  <p>The space (number of thread loop iterations) between the call to <code>modifyFoo</code> and the service can be extremely long, but sometimes, the delay is so short that it is unnoticeable (it seems, in effect, random). It exhibits itself as a frozen UI, as the outer method runs on my UI thread. Obviously, that's a problem. Inserting a 1ms <code>Thread.sleep(1)</code> outside of the synchronous block in the thread loop seems to fix the problem, so my initial thought was "oh, the synchronous block in the while loop is not giving external threads enough time to call the modifyFoo method". However, based on some logging, it does not appear that <code>modifyFoo</code> always executes during this delay, which is what I'd have expected.</p>
  
  <p>So the question is: what is going on here? Once the outside UI thread is waiting at the synchronized block in <code>modifyFoo</code>, why does the inner thread get back ahold of the lock before <code>modifyFoo</code> makes it "out of the wings"? Cannot synchronized blocks "self queue"?</p>