Page 1 of 1

About Question enthuware.ocpjp.v7.2.1329 :

Posted: Thu Jan 30, 2014 1:59 pm
by EpicWestern
What is guaranteed by the JVM about threads?

Explanation:
"Simply put, there is no guarantee which thread will run when and for how much time."

Exactly. So all four answers are wrong. Just my two cents.

Re: About Question enthuware.ocpjp.v7.2.1329 :

Posted: Fri Jan 31, 2014 12:56 am
by admin
Options 3 and 4 are correct because they say the same thing in a different form.

HTH,
Paul.

Re: About Question enthuware.ocpjp.v7.2.1329 :

Posted: Wed Jan 04, 2017 5:04 am
by jagoneye
An additional note:
The thread scheduler will pick the thread with higher thread whenever it gets the chance to!.
Even though this is not given in the options you might get some question with such option. And the answers are correct. There is no guarantee from JVM and threads are usually System dependent.
Because different OS have different priority and thread scheduling.
In Oracle JVM for Linux all thread are considered as same in priority while in windows there are seven levels of priority. I got this from Core Java Volume 1.

Re: About Question enthuware.ocpjp.v7.2.1329 :

Posted: Wed Aug 01, 2018 8:36 am
by __JJ__
I don't see how this is an issue. There exist plenty of synchronization mechanisms to make different threads run at different times.
I cannot see how with all the synchronization mechanisms available, anybody has ever found, whilst using the synchonization mechanisms correctly, that their threads aren't running the way they designed them to because the OS wasn't scheduling them in the way they want.

Put another way, you can make any thread run before or after another thread, using basic things like wait/notify, or CyclicBarriers, Exchangers, CountdownLatch, Semaphore, probably loads of other stuff I haven't even heard of, that I would have thought makes how the OS schedules threads irrelevant. How does the OS come into any of this? Genuinely interested to know.

Re: About Question enthuware.ocpjp.v7.2.1329 :

Posted: Wed Aug 01, 2018 9:05 am
by admin
The issue is when you have two threads that are already ready to run. Once they are already ready to run, it is up to the OS to make the CPU available for those threads. What if the CPU has only one core and you start two threads?

Re: About Question enthuware.ocpjp.v7.2.1329 :

Posted: Wed Aug 01, 2018 9:21 am
by __JJ__
I think I see. So it becomes an issue when you don't explicitly define thread ordering? You still could do (or could have done), but because you haven't, you've left it up to the OS to determine which threads get which processor cycles. Is that correct? Thanks.

Re: About Question enthuware.ocpjp.v7.2.1329 :

Posted: Wed Aug 01, 2018 9:22 am
by admin
That is correct.

Re: About Question enthuware.ocpjp.v7.2.1329 :

Posted: Sun Nov 25, 2018 1:39 pm
by Standalone
Hi, in the explanation it says:
"In some OSs like Windows, CPU time is given to threads in ratio of their priority. While in other OSs like Unix, a lower priority thread executes only after higher priority thread ends."

That states that both OSs distribute CPU time based on thread priority, just in a different way. So why is "CPU time is distributed to the threads according to thread priority" (option B) incorrect?

Re: About Question enthuware.ocpjp.v7.2.1329 :

Posted: Sun Nov 25, 2018 9:13 pm
by admin
Yes, I think it could be interpreted that way. The JavaDoc for Thread class says, "Threads with higher priority are executed in preference to threads with lower priority."
Fixed.
thank you for your feedback!