aspose file tools*
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes Question related to threads 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 "Question related to threads" Watch "Question related to threads" New topic
Author

Question related to threads

shyam ramineni
Ranch Hand

Joined: Jul 08, 2005
Posts: 43
Hi All,

This Question is from Dan's website.
Question no 5 from Threads section in study guide 2.


What are the possible results of attempting to compile and run the program?

a. The first number printed is greater than or equal to 0
b. The first number printed must always be greater than 5000
c. The second number printed must always be greater than 5000
d. The second number printed must always be greater than 6000
e. The synchronized block inside the run method is not necessary
f. Compile-time error
g. Run-time error

Answer given as a and c.
But When I try to run the program. The output is

C:\shyam>java A
0,5007
C:\shyam>java A
0,4997
C:\shyam>java A
0,5007
C:\shyam>java A
0,4997
C:\shyam>java A
10,5007

Can you please explain what might be the reason.

Thanks
Shyam Ramineni


<a href="http://hyderabaditeducation.com" target="_blank" rel="nofollow">http://hyderabaditeducation.com</a>
Joe Sondow
Ranch Hand

Joined: Apr 10, 2005
Posts: 195
That's an interesting discovery you've made, Shyam. Indeed, when I ran the program my results were:

E:\code>java A
0,4997
E:\code>java A
0,5007
E:\code>java A
0,4997
E:\code>java A
0,4997
E:\code>java A
0,5008

My explanation is that the timing mechanism that Java uses on Windows does not supply millisecond precision. So the method calls wait(5000) and System.currentTimeMillis() will be handled by the system as well as the system is capable of handling them, but that won't really be good enough to guarantee that the minimum wait time calculated will really be >= 5000 milliseconds.

Conceptually, Dan's answer is correct according to the Java language specification and programming logic. Unfortunately, counting milliseconds is an operation that tends to be platform-dependent, and the platform that you and I are running doesn't do the job all that well. On the real exam, and on Dan's mock exams, it is safe to assume that there will be no weird errors like this resulting from the underlying platform. What matters for the exam is the theoretical behavior of the code, assuming that it behaves correctly according to the Java Language Specification.


SCJA 1.0 (98%), SCJP 1.4 (98%)
Baiju Scariah
Ranch Hand

Joined: Mar 17, 2005
Posts: 33
Qn is not clear??....

If you call wait method an object - it will release the lock and wait. As soon as the waiting period is completed it will put in the waiting pool for the thread scheduler attention.

Once scheduler assign the CPU that object will continue its excecution.

if the Qn is about the different value printed JAVA - never assure the exact behaviour of thread execution since it depends on other factors also.

Am I answer to your Qn??
Georgy Bolyuba
Ranch Hand

Joined: Feb 18, 2005
Posts: 162
Answer "c" is not correct.

Lets look closer...

This code creates Tread object and thread of execution.
Line //2 is most interesting for me. Will the start() method wait until the run() method ends? No. So, first printed value will be greater than or equal to 0. It's answer "a".


This part of code is more exciting. In line //1 you say: "I will wait for a1 becomes dead, but not longer then 6000 ms." You know that a1 will alive at least 5000 ms. So, according to that facts what can you say about code?

a. The first number printed is greater than or equal to 0 - True.
b. The first number printed must always be greater than 5000 - False. See "a".
c. The second number printed must always be greater than 5000 - False. Thread a1 will not wait will we leave its start() method. So It might run for 1000 when we will call join() and number will be less then 5000.

d. The second number printed must always be greater than 6000 - False. See "c".

e. The synchronized block inside the run method is not necessary - False. wait() must be callend when the current thread owns object's lock (in other words, from synhronized context).

f. Compile-time error - False.

g. Run-time error - False.

The main point:
In this place -> "try {a1.join(6000);}" you cannot tell for how long a1 thread is waiting. It depends on JVM or OS threads' sheduler.

George
[ July 14, 2005: Message edited by: George Bolyuba ]

SCJP 1.4 (100%) Done.<br />SCJD (URLyBird 1.2.3 Started)
Joe Sondow
Ranch Hand

Joined: Apr 10, 2005
Posts: 195
Originally posted by George Bolyuba:
c. The second number printed must always be greater than 5000 - False. Thread a1 will not wait will we leave its start() method. So It might run for 1000 when we will call join() and number will be less then 5000.


George, thread a1 could certainly run for 1000 milliseconds before the main thread calls a1.join(6000), but the second number printed would still have to be greater than or equal to 5000, because the second number printed is the difference between the time before a1.start() was called (startTime), and the time after the a1 thread completed its run method.

The span of time between the moment before start() was called and the moment after a1's run method completed must be at least 5000 milliseconds because of the call to wait(5000). Therefore answer C is correct.

a1's run method must take at least 5000 milliseconds due to its wait(5000) method call.

The second number printed must be calculated after the a1 thread completes, due to the call to a1.join(6000) that occurs before the second number gets calculated.
Georgy Bolyuba
Ranch Hand

Joined: Feb 18, 2005
Posts: 162

George, thread a1 could certainly run for 1000 milliseconds before the main thread calls a1.join(6000), but the second number printed would still have to be greater than or equal to 5000, because the second number printed is the difference between the time before a1.start() was called (startTime), and the time after the a1 thread completed its run method.


Duh. Now it's clear for me. Thanks Joe.

I was totally wrong...

I treated it like this:

[ July 14, 2005: Message edited by: George Bolyuba ]
Marcelo Ortega
Ranch Hand

Joined: May 31, 2005
Posts: 519

Query:

The class extends the Thread class and overrides the run() method. Ok.
But how is this actually creating a thread of execution, don�t we have to pass this derived object to the Thread's constructor as a target???


SCJP 1.4, SCWCD 1.4, SCBCD 1.3, SCJD, SCEA/OCMJEA

Live life to an interface, not an implementation!
Steve Morrow
Ranch Hand

Joined: May 22, 2003
Posts: 657

But how is this actually creating a thread of execution, don�t we have to pass this derived object to the Thread's constructor as a target???
The A object IS-A thread and it IS-A Runnable. Calling start() will start the new Thread.
reubin haz
Ranch Hand

Joined: May 12, 2005
Posts: 287
Originally posted by Joe Sanowitz:
because the second number printed is the difference between the time before a1.start() was called (startTime), and the time after the a1 thread completed its run method.

The span of time between the moment before start() was called and the moment after a1's run method completed must be at least 5000 milliseconds because of the call to wait(5000). Therefore answer C is correct.



Could you tell me why by calling a1.join(6000), the Main thread will not wait at least 6000ms and the option D is not correct?

Thanks


SCJA, SCJP5.0, SCBCD, SCWCD
Joe Sondow
Ranch Hand

Joined: Apr 10, 2005
Posts: 195
Originally posted by reubin nibuer:

Could you tell me why by calling a1.join(6000), the Main thread will not wait at least 6000ms and the option D is not correct?


Check out the API for the join(long millis) method of the Thread class to learn how it works. According to the API, the method

Waits at most millis milliseconds for this thread to die.


So the 6000 value is not the minimum length of time the thread will wait before resuming. It's the maximum length of time the thread will wait for the other thread to die. So join(6000) won't cause the main thread to wait longer than 6000 milliseconds.

The main thread will resume as soon as either one of the following two things happens:

1. The other thread dies, OR
2. 6000 milliseconds go by
 
 
subject: Question related to threads
 
Similar Threads
one more question from Dan's questions
Thread2
Threads
sleep() method
about Thread