Win a copy of Beginning Java 17 Fundamentals: Object-Oriented Programming in Java 17 this week in the Java in General forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Tim Cooke
  • Campbell Ritchie
  • Ron McLeod
  • Liutauras Vilda
  • Jeanne Boyarsky
Sheriffs:
  • Junilu Lacar
  • Rob Spoor
  • Paul Clapham
Saloon Keepers:
  • Tim Holloway
  • Tim Moores
  • Jesse Silverman
  • Stephan van Hulst
  • Carey Brown
Bartenders:
  • Al Hobbs
  • Piet Souris
  • Frits Walraven

Thread

 
Ranch Hand
Posts: 53
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.

 
Ranch Hand
Posts: 59
Android Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.



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?



 
Ranch Hand
Posts: 58
Eclipse IDE Java Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.



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
Ranch Hand
Posts: 53
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
but one of the threads itself is t. How can it synchronize on itself? hence t should never sleep, right?
 
Greenhorn
Posts: 10
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Ranch Hand
Posts: 430
Android VI Editor Debian
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
- 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
Greenhorn
Posts: 10
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Ranch Hand
Posts: 430
Android VI Editor Debian
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Greenhorn
Posts: 10
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


Thank you O. Ziggy. I understand it now. Really appreciate your help.
 
WHAT is your favorite color? Blue, no yellow, ahhhhhhh! Tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
https://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton
reply
    Bookmark Topic Watch Topic
  • New Topic