• 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

what is the output

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

sun preevaluation test




Which two can result? (Choose two.)
in pre
pre in
in post pre
in pre post
pre in post
pre post in
 
Ranch Hand
Posts: 105
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
In my opinion, the output will be,
in pre post or
pre in post

the join method will stop the execution of current thread and appends it to the end of t.
is it right???
 
m prabhu
Ranch Hand
Posts: 79
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
my opinion is,
pre in post
pre post in
are the answers.

reason: due to wait for 2 secs, pre in main will be exceuted first and then due to join and wait command in and post may occur alternatively
[ August 29, 2008: Message edited by: m prabhu ]
 
Ranch Hand
Posts: 148
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
still..post will be the last one to be displayed as it has join which will cause the main thread to wait till thread t finishes..so "post" will be displayed at the end.
 
Greenhorn
Posts: 15
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Two answers? I think it's always pre in post.
 
Ranch Hand
Posts: 180
Netbeans IDE Eclipse IDE Firefox Browser
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
In this case it is always pre in post, the thread t sleep 2 seconds and post always be the last.
 
Ranch Hand
Posts: 129
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Can anyone send me the link for Sun's free evaluation test for scjp1.6
 
Ranch Hand
Posts: 124
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Due to the join call, post must be last. As far as the sleep call,
they always stress that nothing is for certain in thread ordering.
Applying that principle, in and pre could go in any order. So it would
be

pre in post
in pre post
[ August 31, 2008: Message edited by: Ken Truitt ]
 
Ranch Hand
Posts: 52
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The result is always as

pre in post

Because code is like first create thread and start but there is 2 second wait,so thread will wait for two second parallaly with main thread, in between main thread will print pre. Due to join call, main thread will wait till t thread dont finish. After compeletion post will be printed.
 
Ranch Hand
Posts: 206
Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
accoording to me he output should be

in pre post
pre in post

post should be displayed in the end because of the join method
 
Sheriff
Posts: 9707
43
Android Google Web Toolkit Hibernate IntelliJ IDE Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hmmmm....Its so simple and still this thread is going on and on and on.....
 
Ranch Hand
Posts: 177
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Ankit Garg:
Hmmmm....Its so simple and still this thread is going on and on and on.....







I guess this is most common here where people come and say : I think this is true, correct me if I am wrong.
And then the other person comes and says: I think this is it anc correct me if I am wrong.
And going by this tradition:

What I think - The JVM is the BIG BOSS and is free to run any thread when it likes, wake any thread when it wants. But since the post is printed after the join, so post would be printed last-that is GUARANTEED. Nothing else is guaranteed.
Correct me if I am wrong..
 
Ankit Garg
Sheriff
Posts: 9707
43
Android Google Web Toolkit Hibernate IntelliJ IDE Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Somnath you are missing something here....

Blah...Blah...Blah...Blah...Blah...Blah...Blah...Blah...Blah...

Correct me if I am wrong

I hope I will not be kicked out of this forum for this kind of joke...... :roll:
 
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
i agree with m prabhu
. public void run() {
7. try { Thread.sleep(2000); } catch (Exception e) { }
8. System.out.print("in ");
9. }
10. public static void main(String [] args) {
11. Thread t = new Thread(new Order());
12. t.start();
13. System.out.print("pre ");
14. try { t.join(); } catch (Exception e) { }
15. System.out.print("post ");
16. } }

one situation:
line 12,
thread t is at runnable state,but not run,
line 13,"pre" was printed;
line 14,thread t join,so,thread excute run method,and then sleep(2000),at the split second,thread main catch the chance to excute line 15; print"post",then thread-0(thread t) run out of his 2 seconds, and print"in";

other situation:
line 12,
thread t call method start,then he begin run();and sleep(2000)as follow,at this moment,thread main catch the chance to excute13,"pre" was printed,
excute line 14, then thread-0(thread t) is join,and print"in";when thread-0 run over,he become a dead-thread;but main thread still alive,so he should wrork out the last line 15
i hope my answer will help you !
(i'm not good at english, from China)
 
Ankit Garg
Sheriff
Posts: 9707
43
Android Google Web Toolkit Hibernate IntelliJ IDE Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
What is happening here. When you call join on a thread object, the call will return only when the thread of the thread object on which the join is called completes it's run method.

 
Paul Somnath
Ranch Hand
Posts: 177
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Dont know why this post is going so long..
Both the threads can execute in any order, the worker thread may goto sleep but then JVM may wake again! There is no guarantee. The JVM can execute the main thread first or the worker thread first. There is no guarantee.
However, since the main thread joins the worker thread, and after that post is printed, post is guaranteed to be printed last.
There are two scenarios:

1. JVM decides that the worker thread runs first. In this case, the thread sleeps (may not sleep!, depends on JVM) but lets assume it sleeps. Then in gets printed first. After this the main thread runs and prints pre. And finally since the worker thread has terminated, main executes further and prints post.

2. JVM decides that the main thread runs first. In this case, pre gets printed and then the main thread blocks, waiting for the worker thread to complete. The worker thread now resumes and sleeps(again may not sleep as the JVM may wake it up anytime it wants), but lets assume it sleeps. The worker thread prints in and then completes its execution. Main thread now resumes, since the worker thread has completed execution and finally prints post.

So two answers are predictable:
in pre post
pre in post


Hope this closes this thread.
 
Greenhorn
Posts: 17
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
This is in response to Paul.

Sorry to keep the posts coming but I'm still in the dark so I'm afraid that I need to keep beating the proverbial dead horse here.

Quoting Paul Somnath:

JVM decides that the worker thread runs first. In this case, the thread sleeps (may not sleep!, depends on JVM) but lets assume it sleeps. Then in gets printed first.



I don't know how to reconcile this statement with the statement from K&B 1.5 pg 699.

sleep() is guaranteed to cause the current Thread to stop executing for at least the specified sleep duration.



These two statements seem contradictory. If sleep() is guaranteed to cause the current Thread to go into the waiting/blocking/sleeping state for 2 seconds - how can a JVM choose to ignore it?

Paul, you say,

"In this case...the Thread [t] sleeps... Then in gets printed first"

But that doesn't make sense to me. The Thread t is the thread that prints "in". If it gets put to sleep how can this mean that "in" will be printed first? Doesn't t getting put to sleep suggest the opposite, that Thread main will jump in an print "pre"?

I have been banging my head on this one for a couple of days so please forgive my verbosity, but this is driving my crazy. I have put together a scenario that I think might explain the "in pre post". Somebody please put me out of my misery and either confirm it or rip it to shreds!

"in pre post" Scenario:
The main Thread must run first. When the statement is encountered, the JVM selects the Thread t to be executed first. It then encounters the call. K&B 1.5 pg 699 says that sleep() is guaranteed to cause the current Thread to stop executing for at least the specified sleep duration. According to this guarantee, the Thread MUST stop executing for 2 seconds.

(Now this is where the part that is hard to believe happens.) Under some implementation of the JVM, though there are only 2 Threads and one of them is asleep, as part of the no guarantees clause, we cannot say for certain that the main Thread will get a chance to execute at all during the 2000 millisecond period that Thread t spends in the waiting/blocking/sleeping state.

In order for "in" to precede "pre", the main thread just sits in the runnable pool for 2000+ milliseconds while Thread t sleeps. Thread t then awakens, joins the Runnable pool and is selected to enter the Running state. Thread t prints "in"...

Is this scenario actually possible? Can a JVM choose to ignore a call to sleep, or is sleeping guaranteed? Can a JVM choose to sit idly while there is a Runnable Thread (like main) waiting in the pool?

Any specific help would be greatly appreciated.
 
reply
    Bookmark Topic Watch Topic
  • New Topic