Threads again

[cyril vidal]

Hi,
Question 11 of dan chisholm's mock exam: Threads n�2:

 
class A extends Thread {
  String[] sa;
  public A(String[] sa) {
    this.sa = sa;
  }
  public void run() {
    synchronized (sa) {
      while (!sa[0].equals("Done")) {
        try {sa.wait();} catch (InterruptedException ie) {}
      }
    }
    System.out.print(sa[1] + sa[2] + sa[3]);
  }
}
class B {
  private static String[] sa = new String[]{"Not Done","X","Y","Z"};
  public static void main (String[] args) {
    Thread t1 = new A(sa);
    t1.start();
    synchronized (sa) {
      sa[0] = "Done";
      sa[1] = "A";
      sa[2] = "B";
      sa[3] = "C";
      sa.notify();
    }
  }
}
 

Answer : output ABC
Explanations:

Inside the main method a new thread, t1, is started and will move into the running state at the discretion of the thread scheduler. The A.run method invokes the wait method on the String array object, sa, causing the thread to block until another thread invokes the sa.notify method. Before the B.main method invokes sa.notify all of the elements of the String array object, sa, have already been updated.

BUt as the block

  
synchronized (sa) {
      sa[0] = "Done";
      sa[1] = "A";
      sa[2] = "B";
      sa[3] = "C";
      sa.notify();
    }

is synchronized, there's no importance if sa.notify() is called before or after updating sa's array. Anyway, we go out of the synchronized block when all the instructions inside it have been executed
So, the following code should give exactly the same result, no?

synchronized (sa) {
      sa.notify();
      sa[0] = "Done";
      sa[1] = "A";
      sa[2] = "B";
      sa[3] = "C";
     }
  

I tested it, and on my computer, it's the case. But can we generalize?
Thanks for your answer,
Cyril

[Alton Hernandez]

I think when a thread issued a notify()/notifyall() call, what it is saying to other threads in the wait set is, "Hey, I am about to release the lock on this object. Get ready!". However, this does not mean that that thread will give up the lock immediately, nor will it guarantee a certain thread to obtain the lock.
Just my 2 cents

[Miki Muzsi]

Cyril, the notify() method MUST be there in order to make sure that your code will not run forever. Imagine what would happen if t1 gets executed before the main thread gets the lock on sa, i.e before the code below is execuuted:
synchronized (sa) {
sa[0] = "Done";
sa[1] = "A";
sa[2] = "B";
sa[3] = "C";
sa.notify();
}
It would check that: "!sa[0].equals("Done"))", whcich is true, so it goes and it waits! releases the lock on sa (because of wait) and then main can go further with the code above (setting the values of sa). Now if there is NO notify in the end, thread t1 will wait forever, so your program will never end!
Try to put a Thread.yield() or Thread.sleep(10) after you start t1 (so after the t1.start(); call), to give a chance to t1 to start its execution before the main. You will see that without a notify, your program runs forever.
Miki

[cyril vidal]

Miki,
Thanks for your response.
As you say, i'm sure that notify() instruction is necessary so that t1 thread doesn't have to wait for ever.
But my question was more precisely: is the place of this notify() methodin synchronized code necessary at the end?
Normally, it should'nt harm, because the lock is out when all the block has been executed.
But is it really the case?

[Thomas Thomas]

Both the code exactly the same as notify call has nothing to do with releasing of the lock.
Inorder to make sure that code doesn't wait for ever i think it better to use join rather than the wait & notify in the above scenario.
Thomas

[Marlene Miller]

Cyril, you are correct that the notify method can be placed anywhere within the synchronized block.
In very formal terminology,
Notification actions occur upon invocation of methods Object.notify() and Object.notifyAll(). Let thread T be the thread executing either of these methods on Object M, and let N be the number of lock actions by T on M that have not been matched by unlock actions.
If N is greater than zero and this is a notify operation, then, if M's wait set is not empty, a thread U that is a member of M's current wait set is selected and removed from the wait set. (There is no guarantee about which thread in the wait set is selected.) This removal from the wait set enables U's resumption in a wait action. Notice however, that U's lock actions upon resumption cannot succeed until some time after T fully releases the lock for M.
From Proposed revision to Section 17.4, Wait Sets and notification , Doug Lea
Relevant to your question is the last sentence.

[cyril vidal]

The answer to the question ... in the mock exam from the same person, N�3, question 9

If an Object.notify method call appears in a synchronized block, then it must be the last method call in the block.

Response: False.
Explanation:

Suppose that thread T1 is holding the monitor for an object, A, within a synchronized block. If thread T1 calls the notify method immediately after entering the synchronized block, then no other thread can grab the monitor for object A until T1 leaves the synchronized block. For that reason, the transfer of control from thread T1 to any waiting thread can not be accelerated by moving the notify method to an earlier point in the synchronized block

So notify()'s position in synchronized block doesn't matter..