• 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:
  • Campbell Ritchie
  • Paul Clapham
  • Ron McLeod
  • Jeanne Boyarsky
  • Tim Cooke
Sheriffs:
  • Liutauras Vilda
  • paul wheaton
  • Henry Wong
Saloon Keepers:
  • Tim Moores
  • Tim Holloway
  • Stephan van Hulst
  • Carey Brown
  • Frits Walraven
Bartenders:
  • Piet Souris
  • Himai Minh

yield() in synchronized code - a Dan Chisholm question

 
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I wanted to clarify my logic for why the following code works the way that it does:
First the code:

The answers are:
a. Prints: X0Y1X2Y3X4Y5.
b. Prints: X0X1X2Y3Y4Y5.
Initially, I presumed that the a yield() call would mean that either thread would take the lock of the object with it, so that the second thread could not enter the synchronized method since it can't acquire the lock.
Does this mean that because the second thread is blocked on the object and therefore sits in the waiting list for that object, that the thread scheduler allows the first thread to continue without a yield() call and therefore releases the lock in the synchronized method?
Thanks for any help!
 
Ranch Hand
Posts: 1865
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Julian,
Thank you for using my exam.
The following are all of the answer options for the question.


What are the possible results of attempting to compile and run the program?
a. Prints: X0Y1X2Y3X4Y5.
b. Prints: X0X1X2Y3Y4Y5.
c. Prints: X0Y0X1Y1X2Y2.
d. Prints: X0X1X2Y0Y1Y2.
e. Compiler error.
f. Run time error.
g. None of the above.


Since the method is synchronized we know that the value returned by the method will be unique. In other words, both threads will never read the same value. Therefore, answer options c and d can be eliminated. Both answer options 'a' and 'b' are possible because the thread scheduler could allow the two threads to run in any order.
The behavior of the Thread.yield method is platform dependent. There is no guarantee that Thread.yield will cause the running thread to allow a different thread to run.
This is really not a question about the Thread.yield method. I just put it in there so that if you run the program you will be more likely to see a wider variety of results.
The real exam does not emphasize the Thread.yield method. Just remember that the behavior is platform dependent.
 
Julian Reed
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Dan
Thanks for your reply, I understand now!
Kind Regards
Julian
 
Ranch Hand
Posts: 168
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,
But Im still in doubt if calling yield will release the lock or not ....
 
Author and all-around good cowpoke
Posts: 13078
6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The Thread yield() can not release a lock.
Bill
 
Giselle Dazzi
Ranch Hand
Posts: 168
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Therefore, answer options c and d can be eliminated. Both answer options 'a' and 'b' are possible because the thread scheduler could allow the two threads to run in any order.


I agree but If yield does not release the lock, whichever thread starts first will finish before the other gets a chance to hold the lock, so for me the answer would never be
X...Y.. X.. Y...
only
X..X..X.. Y..Y..Y..
or
Y..Y..Y.. X..X..X..
Does that make any sense ?
 
Dan Chisholm
Ranch Hand
Posts: 1865
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Giselle Dazzi:

I agree but If yield does not release the lock, whichever thread starts first will finish before the other gets a chance to hold the lock, so for me the answer would never be
X...Y.. X.. Y...
only
X..X..X.. Y..Y..Y..
or
Y..Y..Y.. X..X..X..
Does that make any sense ?



Giselle,
The getI method is synchronized, but the run method is not. The loop that iterates from 0 to 3 is in the run method so nothing stops both threads from iterating simultaneously. The thread scheduler could allow thread X to run only one loop iteration before allowing thread Y to run only one loop iteration. That sequence of events to repeat three times.
 
Giselle Dazzi
Ranch Hand
Posts: 168
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thank you Dan.
When I think Im starting to know a little ...
 
Ranch Hand
Posts: 65
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
When I run the code I get the following output
Y1X0X3Y2Y5X4
Is this because thread X completes the getI() method and then leaves the running state. Thread Y then completes the run method and prints Y1, then X completes run by printing X0.
I understand that little is guaranteed when talking about the scheduler. In the case above it appears that thread x stops just before it completes the print statement. Can I assume that a thread can leave the running state at any point in execution, meaning even if it has not completed the current statement?
Or am I missing something?
 
Time is mother nature's way of keeping everything from happening at once. And this is a tiny ad:
Free, earth friendly heat - from the CodeRanch trailboss
https://www.kickstarter.com/projects/paulwheaton/free-heat
reply
    Bookmark Topic Watch Topic
  • New Topic