Question related to threads

[shyam ramineni]

Hi All,

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

class A extends Thread {
  public void run() {
    synchronized (this) {
      try {wait(5000);} catch (InterruptedException ie){}
  }}
  public static void main(String[] args) {
    A a1 = new A();
    long startTime = System.currentTimeMillis();
    a1.start();
    System.out.print(System.currentTimeMillis() - startTime + ",");
    try {a1.join(6000);} catch (InterruptedException ie) {}
    System.out.print(System.currentTimeMillis() - startTime);
}}

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

[Joe Sondow]

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.

[Baiju Scariah]

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]

Answer "c" is not correct.

Lets look closer...

    A a1 = new A();
    long startTime = System.currentTimeMillis(); //1
    a1.start(); //2
    System.out.print(System.currentTimeMillis() - startTime + ","); //3

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".

    try {a1.join(6000);} catch (InterruptedException ie) {} //1
    System.out.print(System.currentTimeMillis() - startTime); //2

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 ]

[Joe Sondow]

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]

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:

    
a1.start();
long startTime = System.currentTimeMillis();

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

[Marcelo Ortega]

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???

[Steve Morrow]

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]

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

[Joe Sondow]

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