aspose file tools*
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes what is the output Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of EJB 3 in Action this week in the EJB and other Java EE Technologies forum!
JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "what is the output" Watch "what is the output" New topic
Author

what is the output

m prabhu
Ranch Hand

Joined: Jan 29, 2008
Posts: 79
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
Anoobkumar Padmanabhan
Ranch Hand

Joined: Aug 08, 2007
Posts: 103
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???


Thanks<br /> <br />Anoobkumar<br />SCJP 1.5
m prabhu
Ranch Hand

Joined: Jan 29, 2008
Posts: 79
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 ]
vidhya suvarna
Ranch Hand

Joined: Aug 28, 2008
Posts: 148
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.


SCJP 1.4 - 88%<br />SCWCD 1.5 - Preparing
Igor Lichs
Greenhorn

Joined: Aug 08, 2008
Posts: 15
Two answers? I think it's always pre in post.


SCJA
Ashok Pradhan
Ranch Hand

Joined: Dec 17, 2007
Posts: 180

In this case it is always pre in post, the thread t sleep 2 seconds and post always be the last.
Dean Jones
Ranch Hand

Joined: Dec 29, 2007
Posts: 129
Can anyone send me the link for Sun's free evaluation test for scjp1.6
Ken Truitt
Ranch Hand

Joined: Aug 23, 2007
Posts: 124
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 ]

SCJP 88% | SCWCD 84%
Narendra shah
Ranch Hand

Joined: Feb 28, 2007
Posts: 51
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.


Narendra Shah -- SCJP 5
chander shivdasani
Ranch Hand

Joined: Oct 09, 2007
Posts: 206

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


Enjoy, Chander
SCJP 5, Oracle Certified PL/SQL Developer
Ankit Garg
Sheriff

Joined: Aug 03, 2008
Posts: 9280
    
  17

Hmmmm....Its so simple and still this thread is going on and on and on.....


SCJP 6 | SCWCD 5 | Javaranch SCJP FAQ | SCWCD Links
Paul Somnath
Ranch Hand

Joined: May 19, 2008
Posts: 177
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..


Preparing for SCJP 6.0
Ankit Garg
Sheriff

Joined: Aug 03, 2008
Posts: 9280
    
  17

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:
Jiang zhixiao
Greenhorn

Joined: Jul 01, 2008
Posts: 13
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

Joined: Aug 03, 2008
Posts: 9280
    
  17

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

Joined: May 19, 2008
Posts: 177
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.
Trey Carroll
Greenhorn

Joined: May 06, 2008
Posts: 17
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.


Trey Carroll<br />======================<br />Studying for the SCJP
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: what is the output
 
Similar Threads
A question of Thread from Sun's Assessement test
Thread - join()
Threading question
Thread Question from SUN's assessment exam
Mock Exam Official Sun Question