• 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
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Thread - join()

 
Ranch Hand
Posts: 41
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
This is from the sun profficiency exam:



Which two can result? (Choose two.)
A)in pre
B) pre in
C)in post pre
D)in pre post
E)pre in post
F)pre post in

Answers = D and E

For E to happen, the “Order” thread would want to run straight away (at line 12). Why wouldnt the sleep() at line 7 switch the context back to the main thread? Where the result would be pre in post again??
 
Ranch Hand
Posts: 430
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I didn't start the Thread part yet, but ...

I don't think sleep has something to do to switch context. It just makes the thread stop for a certain time.
After the join, you can assure that "post" will be the last to be printed.
 
Robert O'Leary
Ranch Hand
Posts: 41
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Leandro Coutinho wrote:I didn't start the Thread part yet, but ...

I don't think sleep has something to do to switch context. It just makes the thread stop for a certain time.
After the join, you can assure that "post" will be the last to be printed.



sleep() suspends a thread. the thread goes into a blocked state in this case for 2 seconds. the JVM then selects a runnable thread. i would assume that it selects the main thread in this case as there is no other thread running in this program
 
Ranch Hand
Posts: 194
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You don't have to worry about the lock here. If main happens to execute first (which is unpredictable), "pre" is printed, then your guaranteed that "post" won't print until after "in" because of the call to join.

Thread.join() says I will wait to execute until the thread I'm calling join on is finished executing.
 
Robert O'Leary
Ranch Hand
Posts: 41
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Ryan Beckett wrote:You don't have to worry about the lock here. If main happens to execute first (which is unpredictable), "pre" is printed, then your guaranteed that "post" won't print until after "in" because of the call to join.

Thread.join() says I will wait to execute until the thread I'm calling join on is finished executing.



i know ryan, but if the "Order" thread gets in first - it will encounter the sleep() statement before the print statement. Wouldnt the suspension of the "Order" thread result in the main thread gettin scheduled then? This would mean that the result printed would be : "pre in post" as well
 
Ryan Beckett
Ranch Hand
Posts: 194
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yes, that could happen too. The point is that main() won't execute any lines after Thread.join() until the other thread dies.
 
author
Posts: 23951
142
jQuery Eclipse IDE Firefox Browser VI Editor C++ Chrome Java Linux Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

This question has come up a few times in this forum -- it may be a good idea to search for old discussions.

The jist of the previous discussions were... Yes, D is theoretically possible -- as schedulling is not defined. However, the chances of having a JVM that is so broken, that it could not schedule the main thread to run, within 2 seconds, and no other threads in the program, is highly improbable. Common sense says D can't be right.

Henry
 
Robert O'Leary
Ranch Hand
Posts: 41
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Henry Wong wrote:
This question has come up a few times in this forum -- it may be a good idea to search for old discussions.

The jist of the previous discussions were... Yes, D is theoretically possible -- as schedulling is not defined. However, the chances of having a JVM that is so broken, that it could not schedule the main thread to run, within 2 seconds, and no other threads in the program, is highly improbable. Common sense says D can't be right.

Henry



Thanks Henry! I should of probably given the forum a quick search to see if this was encountered beforehand..
 
Ranch Hand
Posts: 30
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
This exam question is driving home the point that there is absolutely no guarantee regarding the ordering of thread behavior. In theory, the main() thread could be running so slowly - or interrupted - such that 2 seconds could pass prior to reaching line 13.

Additionally, it's begging the suggestion that a developer could use a better mechanism than Thread.sleep() to more reliably influence the timing multiple threads. Instead, one could consider a locking mechanism or perhaps some sort of flag to determine when code should run based on a programmatic or persistent state.
 
Robert O'Leary
Ranch Hand
Posts: 41
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Henry Wong wrote:
This question has come up a few times in this forum -- it may be a good idea to search for old discussions.

The jist of the previous discussions were... Yes, D is theoretically possible -- as schedulling is not defined. However, the chances of having a JVM that is so broken, that it could not schedule the main thread to run, within 2 seconds, and no other threads in the program, is highly improbable. Common sense says D can't be right.

Henry



Henry - I was looking at the previous threads about these types of Thread problems. If there was an answer for this question specifying "Result is unpredictable", would it be the correct answer? As there is a remote chance of the output as in E

So saying the question was changed to this:

What is the result? (Choose one.)
A)in pre
B) pre in
C)in post pre
D)in pre post
E)pre in post
F)pre post in
G) Result is unpredictable

Would G be the correct answer?

Im just interested in what the exam expects the correct answer to be. If the question was posed as above, I personally would go for answer E.

I would assume that the exam is clearer on these type of questions; or at the very least you'd be able to infer the correct answer by the amount of correct answers they request (like the original question).
 
Steven Landers
Ranch Hand
Posts: 30
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
That is correct - it would be technically unpredictable - despite the fact that one of the possibilities is very unlikely.
 
Destiny's powerful hand has made the bed of my future. And this tiny ad:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic