About Question enthuware.ocpjp.v7.2.1329 :
Moderators: Site Manager, fjwalraven
-
- Posts: 17
- Joined: Wed Jan 22, 2014 12:35 pm
- Contact:
About Question enthuware.ocpjp.v7.2.1329 :
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.
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.
-
- Site Admin
- Posts: 10103
- Joined: Fri Sep 10, 2010 9:26 pm
- Contact:
Re: About Question enthuware.ocpjp.v7.2.1329 :
Options 3 and 4 are correct because they say the same thing in a different form.
HTH,
Paul.
HTH,
Paul.
If you like our products and services, please help us by posting your review here.
-
- Posts: 97
- Joined: Wed Dec 28, 2016 9:00 am
- Contact:
Re: About Question enthuware.ocpjp.v7.2.1329 :
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.
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.
-
- Posts: 125
- Joined: Thu Jul 05, 2018 6:44 pm
- Contact:
Re: About Question enthuware.ocpjp.v7.2.1329 :
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.
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.
-
- Site Admin
- Posts: 10103
- Joined: Fri Sep 10, 2010 9:26 pm
- Contact:
Re: About Question enthuware.ocpjp.v7.2.1329 :
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?
If you like our products and services, please help us by posting your review here.
-
- Posts: 125
- Joined: Thu Jul 05, 2018 6:44 pm
- Contact:
Re: About Question enthuware.ocpjp.v7.2.1329 :
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.
-
- Site Admin
- Posts: 10103
- Joined: Fri Sep 10, 2010 9:26 pm
- Contact:
Re: About Question enthuware.ocpjp.v7.2.1329 :
That is correct.
If you like our products and services, please help us by posting your review here.
-
- Posts: 5
- Joined: Thu Nov 30, 2017 4:37 pm
- Contact:
Re: About Question enthuware.ocpjp.v7.2.1329 :
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?
"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?
-
- Site Admin
- Posts: 10103
- Joined: Fri Sep 10, 2010 9:26 pm
- Contact:
Re: About Question enthuware.ocpjp.v7.2.1329 :
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!
Fixed.
thank you for your feedback!
If you like our products and services, please help us by posting your review here.
Who is online
Users browsing this forum: No registered users and 4 guests