Page 1 of 1

About Question enthuware.ocpjp.v7.2.1711 :

Posted: Thu Sep 19, 2013 5:22 am
by Wisevolk
Hello,
If we can say that priority thread are not guaranteed, what about the first answer even if there is the most tinies probabilities ?

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

Posted: Thu Sep 19, 2013 8:06 am
by admin
Well, can you show a situation when any other output except the one mentioned in option 3 is possible?

HTH,
Paul.

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

Posted: Sun Sep 29, 2013 7:30 am
by Wisevolk
I can't show a specific situation because of thread unpredictability, but what I say is if the "first" thread in the code is not run before the second finish the first answer is right to ?

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

Posted: Sun Sep 29, 2013 8:59 am
by admin
That is not a valid argument. You are misunderstanding what thread unpredictability means. Thread Unpredictability does not mean that just about any output can occur. All the output can be predicted, but which output will occur when is what is unpredictable.

If you can show a situation that is theoretically possible, then you can use the unpredictability argument to explain why that output did not occur when you ran program. Thread unpredictability does not prevent you from determining a situation where the output that you are claiming will occur.


HTH,
Paul.

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

Posted: Fri Oct 18, 2013 12:36 pm
by DesRenthuware
Hi.

Also a bit confused by this... if this was running on a Unix like system and both threads could be forced to wait, while a higher priority thread ran under the OS. Once the higher priority thread ended, the order in which these threads execute is unknown. "Thread 2 (the printer)" could be executed before "Thread 1 (the remover)", resulting in the first answer being correct?

Am I completely missing the boat?

Cheers

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

Posted: Fri Oct 18, 2013 12:46 pm
by admin
The order in which the two threads will run is unknown even without any other higher priority thread in the picture. But that will still not generate the output mentioned in option 3. So option 1 is still wrong.

HTH,
Paul.

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

Posted: Fri Oct 18, 2013 1:20 pm
by DesRenthuware
Hmmm....

Completely misunderstood the answer to three. What you are saying is, it could print:

a, b, c, || b, c, || a, c, etc.

but never

a, || b, || a, b, || b, a

by themselves without 'c'?

I (and I suspect Wisevolk) were interpreting the question (and answer 3 in particular) as:

It can print any combination except combinations that contain a || b in conjunction with c (on the assumption that a and b had already been removed).

Cheers

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

Posted: Fri Jul 31, 2015 8:39 pm
by gk_javauser
I would like to understand this as well ,why choice 1 is not a valid answer.

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

Posted: Sat Aug 01, 2015 6:20 am
by admin
Please read the discussion above.

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

Posted: Sat Aug 01, 2015 8:34 pm
by admin
I have confirmed that it has been fixed in v 1.94
HTH,
Paul.

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

Posted: Sun Sep 06, 2015 12:41 am
by boyonsea
re read the explanation multiple times, still dont understand why option 1 is incorrect.

if thread 2 starts before thread 1, it will print a,b,c or b,a,c or any other combo since the order is not known

Read discussion above is also misleading, since DesRenthuware explicit suggestion "a, || b, || a, b, || b, a " was not confirmed.

Thanks

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

Posted: Sun Sep 06, 2015 1:04 am
by admin
Can the code ever print just a? or just b? or a, b? or b, a? The answer is no. Hence, option 1, which says "It may print any combination of the keys." cannot be correct. Right?

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

Posted: Sun Sep 06, 2015 1:06 am
by admin
DesRenthuware wrote:Hmmm....

Completely misunderstood the answer to three. What you are saying is, it could print:

a, b, c, || b, c, || a, c, etc.

but never

a, || b, || a, b, || b, a

by themselves without 'c'?
Yes, that is correct.

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

Posted: Thu Jan 05, 2017 6:48 am
by jagoneye
The wordings of the answer options are difficult to understand. But the right answer is indeed the third option.

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

Posted: Sat Mar 11, 2017 2:46 pm
by rohitbe
Highly unlikely for the first thread to not get a chance to run before the second thread actually starts running but possible(Anyways, cannot be proved theoretically).

Then this theoretical principle should be applied for the explanation of your question viewtopic.php?f=2&t=1812
Can you prove here theoretically that main thread will not call 'a.interrupt()' while the other thread is sleeping? (condition - you are not allowed to change the code in the question as with the above case)

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

Posted: Sat Mar 11, 2017 8:42 pm
by admin
Did you read the explanation for question 2.1324?
It says that same thing that you are saying, "Even though the thread is sleeping for 10 seconds and it is very probable that the main thread will execute and call a.interrupt() (which will cause the sleeping thread to receive an InterruptedException), this behavior cannot be guaranteed. It is possible, even though highly unlikely, that the sleeping thread will complete its 10 seconds sleep and the main thread may not get a chance to run and call a.interrupt() in those 10 seconds. In this case there won't be any exception."

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

Posted: Sat Mar 11, 2017 11:22 pm
by rohitbe
Yes, I have read it and understood it the way you explained it. It's theoretically not possible to explain that main thread will not be calling 'a.interrupt()' while the other Thread is sleeping for 10 seconds. I agree, there is 99% possibility of InterruptedException being thrown but 1% of not being thrown.
IF you yourself are accepting a possibility of a highly unlikely situation that can't be proved theoretically, then why not here in this question.

Same thing goes here for this question - There is 99% possibility that second thread started by main will be executed after first but 1% possibility that the first thread(triggered by main) may be kept on hold by OS scheduler due to some reason while the second thread(also triggered by main) has started running.
For this question, I agree, it is very probable that the main thread will execute the first Iterator thread before starting with the second but it is not guaranteed. Like, main thread has started the first iterator thread but due to some reason, its run() is still not called while the second iterator thread had been started by main in that duration and whose run() is executed before first.

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

Posted: Sun Mar 12, 2017 1:06 am
by admin
Yes, the same goes for this question as well. It is possible that the second thread may get to execute first. But so what? How does that change the answer?

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

Posted: Sun Mar 12, 2017 2:31 am
by rohitbe
Got it.
Anyways, with either case, it's never gonna exclude 'c' from the combination. So combinations without 'c' are never possible.
Sorry misinterpreted the answer options. :)