Thread

[Jeet Jain]

How can 4 ever print before 2? Thread t will never enter synchronized block because it does not hold lock on itself. But 2nd thread can so it sleeps guaranteeing "2" be printed before 4, right? Right answer says it can be printed before.

 class Locker extends Thread {
 private static Thread t;
 public void run() {
 if(Thread.currentThread() == t) {
 System.out.print("1 ");
 synchronized(t) { doSleep(2000); }
 System.out.print("2 ");
 } else {
 System.out.print("3 ");
 synchronized(t) { doSleep(1000); }
 System.out.print("4 ");
 }
 }
 private void doSleep(long delay) {
 try { Thread.sleep(delay); } catch(InterruptedException ie) { ; }
 }
 public static void main(String args[]) {
 t = new Locker();
 t.start();
 new Locker().start();
 } }

[nitin sethi]

Jeet Jain wrote:How can 4 ever print before 2? Thread t will never enter synchronized block because it does not hold lock on itself. But 2nd thread can so it sleeps guaranteeing "2" be printed before 4, right? Right answer says it can be printed before.

 class Locker extends Thread {
 private static Thread t;
 public void run() {
 if(Thread.currentThread() == t) {
 System.out.print("1 ");
 doSleep(2000); // Added by me; You can assume the thread scheduler did so for some reason.
 synchronized(t) { doSleep(2000); }
 System.out.print("2 ");
 } else {
 System.out.print("3 ");
 synchronized(t) { doSleep(1000); }
 System.out.print("4 ");
 }
 }
 private void doSleep(long delay) {
 try { Thread.sleep(delay); } catch(InterruptedException ie) { ; }
 }
 public static void main(String args[]) {
 t = new Locker();
 t.start(); // This statement just makes the Thread t's state as runnable. It's not guaranteed to run before the next statement is executed.
 new Locker().start(); // If the above thread doesn't run and this thread's run method is invoked, this thread will acquire the lock on the object t 1st and so 4 is printed 1st.
 } }

Read the comments above.

Thread t will never enter synchronized block because it does not hold lock on itself.

I don't quite get what you mean by this? Could you explain a bit more?

[Suhrid Karthik]

Jeet Jain wrote:How can 4 ever print before 2? Thread t will never enter synchronized block because it does not hold lock on itself. But 2nd thread can so it sleeps guaranteeing "2" be printed before 4, right? Right answer says it can be printed before.

 class Locker extends Thread {
 private static Thread t;
 public void run() {
 if(Thread.currentThread() == t) {
 System.out.print("1 ");
 synchronized(t) { doSleep(2000); }
 System.out.print("2 ");
 } else {
 System.out.print("3 ");
 synchronized(t) { doSleep(1000); }
 System.out.print("4 ");
 }
 }
 private void doSleep(long delay) {
 try { Thread.sleep(delay); } catch(InterruptedException ie) { ; }
 }
 public static void main(String args[]) {
 t = new Locker();
 t.start();
 new Locker().start();
 } }

4 can be printed before 2, if say the thread referenced by the statement "new Locker().start()" starts executing before the thread t. If it gets a chance to sleep before t does, then 4 will be printed before 2.

Thread t will never enter synchronized block because it does not hold lock on itself. But 2nd thread can ...

Both the threads will attempt to acquire t's lock and enter the synchronized block.

[Jeet Jain]

but one of the threads itself is t. How can it synchronize on itself? hence t should never sleep, right?

[Matt Gottlieb]

Still having a lot of trouble with this one. Any help would be appreciated. The answer in the book says "...either thread could hold the monitor lock of "t". The other thread will wait until the lock is released and both threads will continue to normal completion"

It seem to me that whichever thread first gets the monitor lock "t" will complete first, because once that thread releases the lock on "t", the other thread will need to enter the "doSleep" method.

Thanks,

-Matt

[O. Ziggy]

- Whichever thread gets the lock first will go to sleep first
- When a thread goes to sleep it does not release its lock
- Only one thread will be asleep at any one time - The reason being that the object being used for the lock is a static object so there is only one instance.
- There is nothing wrong with a thread holding a lock on itself - Its exactly the same as saying synchronized(this){}

4 can print before 2 if the second thread releases the lock but the scheduler lets thread 2 continue. Just because the lock is released does not mean that another thread waiting for the lock will be put into the "running" state straight away. Thread 2 can release the lock and still complete before thread one has started sleeping.

[Matt Gottlieb]

Ziggy:

First, thank you very much for your reply. I definitely appreciate your help.

Regarding your statements - I totally agree that whichever thread gets the lock first will sleep first, sleeping threads do not release the lock, and "t" can acquire a lock on itself.

I also think the fact that the locked object is static means that both threads are competing for the same lock, so only one thread will be able to synchronize on the object "t" at a time.

So far, so good.

So this is where I am still having trouble:

1) I think either thread could be picked by the JVM to run first so the first output is either "1" or "3".

2) Next - one of two things happen - a) the alternate thread could be picked to run and the output is whichever "3" or "1" did not print in step 1 above. b) Or, the first thread picked to run acquires the lock on "t", sleeps, and the alternate thread prints whichever "3" or "1" did not print in step one above. Either way - the first two digits of the output are "3" and "1" in no determinate order.

3) Now one of the two threads acquires the lock and goes to sleep, and the other thread must wait because of the lock.

4) Once the sleep period is over, again one of two things happen - either the thread that acquired the lock continues and prints out its final print statement, or the JVM switches to the other thread. If the JVM switches to the other thread, this thread goes to sleep and the first thread will print out its final print statement.

5) So it seems to me, whichever thread is chosen to run first, will complete first . Either by virtue of the JVM continuing with that thread after the lock is released, or the JVM allowing the other thread to run - thus immediately putting the other thread to sleep, which again allows the first selected thread to complete.

So in this case, my answer would be that the output could be either:

1 3 2 4 - (first thread acquires lock first and finishes first)

3 1 4 2 - (second thread acquires lock first and finishes first)

However, book says that 1 3 4 2 and 3 1 2 4 are valid answers - which I am having trouble understanding.

Thanks,

-Matt

[O. Ziggy]

Matt Gottlieb wrote:
4) Once the sleep period is over, again one of two things happen - either the thread that acquired the lock continues and prints out its final print statement, or the JVM switches to the other thread. If the JVM switches to the other thread, this thread goes to sleep and the first thread will print out its final print statement.

No necessarily. Don't forget that the two threads in the program are not the only two threads running in the JVM. There are other threads running on the JVM (e.g. the main thread). This means that when thread1 wakes up it is not guaranteed that it will continue. It could also be put in a runnable state (after it has gone to sleep) while thread2 is running.

Here is an example of how i think some of the answers could happen (Please note i am not an expert so this is just what i think and i could be wrong)

1 3 4 2 - T1 prints 1 --> T2 prints 3 --> T1 acquires lock and goes to sleep --> T1 releases lock --> T2 acquires lock (T1 is not yet runnable) --> T2 wakes up and prints 4 --> T1 prints 2
or
1 3 4 2- T1 prints 1 --> T2 prints 3 --> T2 acquires lock and goes to sleep --> T2 releases lock --> T1 acquires lock and sleeps --> T2 prints 4 while T1 is asleep --> T1 wakes up and prints 2

3 1 2 4 - T2 prints 3 --> T1 prints 1 --> T1 acquires lock and sleeps --> T1 wakes up and goes on to print 2 --> T2 acquires lock and sleeps, wakes up and prints 4

I hate these thread questions because i find that there is usually more than one answer and they are always very confusing..

[Matt Gottlieb]

Thank you O. Ziggy. I understand it now. Really appreciate your help.