• 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

Whizlabs Thread Question

 
Greenhorn
Posts: 26
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The following is a question from Whizlabs SCJP 1.4 mock test:

What will happen when you attempt to compile and run the following code:

class MyThread extends Thread{
public void run(){System.out.println("MyThread: run()");}
public void start(){System.out.println("MyThread: start()");}
}
class MyRunnable implements Runnable{
public void run(){System.out.println("MyRunnable: run()");}
public void start(){System.out.println("MyRunnable: start()");}
}
public class MyTest{
public static void main(String[] args){
MyThread myThread = new MyThread();
MyRunnable myRunnable = new MyRunnable();
Thread thread = new Thread(myRunnable);
myThread.start();
thread.start();
}
}

Whizlabs answer:
Prints: "MyThread: start() followed by MyRunnable:run()"

I thought the answer should be "None of the above".

My thinking is that theoretically the thread referenced by myThread could remain in a Runnable state after starting with the main thread continuing to run. The main thread would call start() on the thread referenced by thread. At that point, myThread and thread would both be in the pool of Runnable threads and you cannot predict which one of them the thread scheduler would choose to run first. I thought that would mean the output is not guaranteed to be: "MyThread: start() followed by MyRunnable:run()" but could possibly be "MyRunnable: run() followed by MyThread: start()".

I don't know if I am wrong and if there something that I'm not understanding. I just want to make sure I know what the correct logic is should there be a similar question on the actual test. Could someone please help me with this? Thanks very much in advance!
 
Ranch Hand
Posts: 165
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by catherine powell:
My thinking is that theoretically the thread referenced by myThread could remain in a Runnable state after starting with the main thread continuing to run. The main thread would call start() on the thread referenced by thread. At that point, myThread and thread would both be in the pool of Runnable threads and you cannot predict which one of them the thread scheduler would choose to run first. I thought that would mean the output is not guaranteed to be: "MyThread: start() followed by MyRunnable:run()" but could possibly be "MyRunnable: run() followed by MyThread: start()".



If I understand it correctly (and it's quite possible that I don't!), myThread will not enter the "Runnable" state. After construction, a thread is in the "New" state until it is started. However, a MyThread can not be started because start() is overriden, and Thread.start() never gets called (and there's nothing magical about calling a method that happens to be called "start").

As an aside, if the lines

were the other way round:

then I think the output would be indeterminate.
 
Ranch Hand
Posts: 572
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
myThread.start() will not start the thread, infact it calls the start method defined your class. So there is one thread main running only when myThread.start() was called. Whereas the other thread started in next line. So Whizlab answer is correct
 
catherine powell
Greenhorn
Posts: 26
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I got it now...thank you guys very much!
 
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Whereas the other thread started in next line.



I thought that second thread will also fail to start but it is not so.
Can you please explain me why is so?
 
Matt Russell
Ranch Hand
Posts: 165
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
vivek: What made you think the second thread would fail to start?
 
Ranch Hand
Posts: 1274
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi cowgals &boys,

we have here two different things,
first:


MyThread is subclassing Thread but it does not only override run() but also start().

The original start() method of class Thread should invoke run().
But in this case, start() is overriden and just prints "MyThread: start()". The run() method of MyThread is never invoked.

second

Here we have a Runnable with its run() method (wouldn't compile without) plus an additional start() method.
The Runnable is passed to the Thread constructor.
When a Runnable is passed into the constructor of a Thread, the run() Method of the Runnable (and not of Thread) will be invoked. And this prints "MyRunnable: run()" in this example.
Here the start() method of the Runnable is never invoked.

Yours,
Bu.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic