• 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

The order of main thread & its thread executions

 
Ranch Hand
Posts: 451
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I did an exercise from" Practice Exams Java", here is a question that I don't understand:
class Mosey implements Runnable {
public void run() {
for(int i = 0; i < 1000; i++) {
System.out.print(Thread.currentThread().getId() + "-" + i + " ");
} } }
public class Stroll {
public static void main(String[] args) throws Exception {
Thread t1 = new Thread(new Mosey());
//insert code here
}
}

A. t1.setPriority(1);
new Mosey().run();
t1.start();

B. t1.setPriority(9);
new Mosey().run();
t1.start();

C. t1.setPriority(1);
t1.start();
new Mosey().run();

D. t1.setPriority(8);
t1.start();
new Mosey().run();

Answer (for Objective 4.2):
A, B, and C are correct. For A and B, the main thread executes the run() method
before it starts t1. C is correct because t1 is set to a low priority, giving the main thread
scheduling priority.D is incorrect because by setting t1’s priority to 8, the t1 thread will tend to execute
mostly before the main thread.


I have a question regarding to "the main thread executes the run() method before its starts t1" . Does it mean if the main thread starts its execution before it starts another thread, the main thread will always execute most of its code before this thread's execution?
But in K&B's book, p714, it says "There is nothing in the Java specification that says threads will start running in the order in which they were started (in other words, the order in which start() was invoked on each thread).
I think there is no guarantee of any execution order when the main thread executes its code first or later.

 
Bartender
Posts: 1558
5
Eclipse IDE Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Helen,

First of all, I'm not getting the question at all. All I can see is : two classes, followed by few options. Is it about output? Is it about 'which code from below, when replaced at line x will work' kind of question?

I'm assuming the question to be : which out of below snippets will give similar output to above code.

Now, coming to your question :

If there is x lines of serial(not concurrent) code before threading code, then serial code will be executed before threading. No matter what.

This means, in given code (the one with 2 classes), no matter how high or low the priority of thread is, will always execute before

Now, coming to K&B statement :

There is nothing in the Java specification that says threads will start running in the order in which they were started (in other words, the order in which start() was invoked on each thread)



All they are trying to say is : if 5 threads a,b,c,d,e are started in alphabetical order, then that does not give guarantee that thread a will actually start before thread b and so on. It is possible that thread e is the first one to be started, and/or thread a is the last one to be started.

I hope this helps.
 
Helen Ma
Ranch Hand
Posts: 451
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Sorry that I forgot the question. The question is:
Which of the following code fragments, inserted independently at line 10, will probably run
most (or all) of the main thread’s run() method invocation before running most of the t1
thread’s run() method invocation? (Choose all that apply.)
 
Helen Ma
Ranch Hand
Posts: 451
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi, everyone.
Based on the question and the code above, I cannot believe that new Mosey().run() will probably run for most of the time before the t thread.
When JVM execute the main thread and its threads, there is no guarantee in any order of execution.

1. Setting the priority of a thread is one of the possibility to make a thread executes before another one. But that does not guarantee.
2. But new Mosey().run() starts it execution before t1.run(). How can we predict new Mosey().run() will execute for most of the time before t thread's execution?
 
Anayonkar Shivalkar
Bartender
Posts: 1558
5
Eclipse IDE Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Helen Ma wrote: How can we predict new Mosey().run() will execute for most of the time before t thread's execution?


This is because, when we say it does not create a thread, but will simply make a call to 'run' method of Mosey class. This is nothing but a simple method invocation inside the main thread.
So, once the run method is executed, then only next statement i.e. will start its execution.

This is the difference between obj.run() and obj.start().

I hope this helps.
 
Helen Ma
Ranch Hand
Posts: 451
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi, thanks.
But I think the main thread and the t thread will execute in a round robbin fashion probably. For example, the main thread may execute 2 steps, then t thread execute 2 steps, then main thread turns its turn and then t thread takes it turn.
In the other words, the two threads (main thread and t thread) will take their turns to execute probably.
I cannot guarantee one thread executes for most of the time before another thread execution.
 
Rancher
Posts: 3742
16
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You're missing the point that Anayonkar is making. The t1 thread won't start until t1.start() is called and in A and B, t1.start won't be called until new Mosey().run() has finished executing. So in A and B new Mosey().run() is guaranteed to finish before the t1 thread even starts.
 
Helen Ma
Ranch Hand
Posts: 451
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
So, is scenario 1 possible?
Scenario 1:
1. new Mosey().run() is executed by the main thread and it executes 2 steps out of 1000 steps
2. t1.start() is invoked and t1 starts its execution for 2 steps out of 1000 steps.
3. The main thread takes its turn and repeats 1.
4. t1 takes its turn and repeats 2.

Scenario 2 as described by the suggested solution from the book: main thread executes most of its steps before t1 is started and running.
1. Main thread executes new Mosey().run() for 800 steps, for example.
2. t1.start() is invoked then and t1 starts its execution.
3. Main thread continues.
4. t1 continues.

Scenario 3 may be possible :
1. Main thread executes and completes.
2. t1.start is invoked and t1 completes.


Is scenario 1 possible?
 
Helen Ma
Ranch Hand
Posts: 451
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
After some second thought, I think my scenario 1,2 are not possible.
Before , I thought the JVM starts the main thread and then starts the t1 thread, so that both threads can be executed in round robbin fashion.
But JVM does not work in this way. JVM starts main thread first and let main thread executes new Mosey().run() . When main thread completes the new Mosey().run(), the main thread starts t1 thread.

Is this statement correct?
 
Joanne Neal
Rancher
Posts: 3742
16
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Helen Ma wrote:Is scenario 1 possible?


No. If new Mosey().run() appears in the code before t1.start() then new Mosey().run() will complete before t1.start() is even called.
 
Joanne Neal
Rancher
Posts: 3742
16
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Helen Ma wrote:Is this statement correct?


Yes
 
Greenhorn
Posts: 5
Notepad
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Everyone,

my question is considering the "C" answer option.

the KandB book states:

"Some JVM's might not recognize ten distinct values. Such a JVM might
merge values from 1 to 10 down to maybe values from 1 to 5, so if you have, say, ten
threads each with a different priority, and the current application is running in a
JVM that allocates a range of only five priorities, then two or more threads might be
mapped to one priority."

what dosent mean (to me), that such a JVM is not possible, where all the 10 prio levels are mapped to 1 - such a JVM doesent use proirity at all (maybe on an older mobilephone implementation or some old ARM-JVM whatever). and in this case it is well possible thath the jvm decide at t1.start() "okay whatever i ll run t1-s run() til the and after i get back to you main()". What would mean in this case that t1 ll complete, and only after ll main()-s new mosey().run() start. And if such case could exists the answer C is no more right, isnt it?

i know it sounds little out-of-world-ish, but onestly i was really suprised to see this C answer as right, after ive read in the KandB book:
"In most JVMs, however, the scheduler does use thread priorities in one important
way: If a thread enters the runnable state, and it has a higher priority than any of
the threads in the pool and a higher priority than the currently running thread,
the lower-priority running thread usually will be bumped back to runnable and the
highest-priority thread will be chosen to run. In other words, at any given time the
currently running thread usually will not have a priority that is lower than any of
the threads in the pool. In most cases, the running thread will be of equal or greater
priority than the highest priority threads in the pool. This is as close to a guarantee
about scheduling as you'll get from the JVM specification"

but what the heck, ask the question directly to the JVM: System.out.print("as close to a guarantee"=="guarantee"); ;)

what do you think?


ps.: i give it a try to answare my own question as: as if a question ("...will probably run most...") mentions probably considering Thread-priorities scenario, you should treat statements about jvm and priorities without "usually" "in most cases" "as close to a" words, and deal with the situation in that fashion. We could call this "explicit thread priority uncertainty erasure". Sorry about that, just making fun, im really interested in any serious thoughts about that!!

reply
    Bookmark Topic Watch Topic
  • New Topic