Page 1 of 1

About Question enthuware.ocpjp.v11.2.3654 :

Posted: Thu Oct 13, 2022 9:46 am
by aPerson
Hi, if you include the synchronized part mentioned in the answer it will print 25000. Is this guaranteed to happen every time? If so; why can't the System.out.println at the end get a lower count-number from when the for loop had just started (similar to when there was no "synchronized")? Is it because the synchronization of count means that the variable can't be used until all synchronized operations on it are finished?

Re: About Question enthuware.ocpjp.v11.2.3654 :

Posted: Thu Oct 13, 2022 10:33 am
by admin
1. Yes, it is guaranteed that count will be 25000 if it is incremented in the synchronized block.
2. The print statement will not be executed until all thread are done because of the line es.awaitTermination(10, TimeUnit.SECONDS); But you are right. System.out.println(count); may still print lower count (even 0) because the count variable is not volatile. So the modifications done to it from other threads may not be visible to the main thread.

The right option should mention that the print statement should also be within a synchronized block:

Code: Select all

synchronized(TestClass.class) 
{   
   System.out.println(count);
}
Updated.
thank you for your feedback!

Re: About Question enthuware.ocpjp.v11.2.3654 :

Posted: Fri Oct 14, 2022 6:54 am
by aPerson
Thanks for the reply:) I have more questions though:
1. The awaitTermination does not guarantee that the threads are finished (iterating to 25000) does it? I tried setting the wait-time to 1 microsecond, and having the two synchronized blocks you mentioned. The result was less than 25000.
2. Would it be correct to say that the awaitTermination must be validated to see if it actually terminated the 5 new threads?
3. So, in the synchronized, 1-microsecond(and probably not terminated) case; is the synchronized print getting the lock in between the new threads giving a low count?
4. If this is correct wouldn't a threadsafe version of the code be one that A: validates that termination has happened, and B: has a synchronized iteration-part (not the print), OR an atomic count OR a volatile count?

Re: About Question enthuware.ocpjp.v11.2.3654 :

Posted: Fri Oct 14, 2022 7:13 am
by admin
I think I spoke too soon. After going through the question again, I realize that the question is asking about whether the code is thread safe or not. It is not asking whether 25000 will be printed or not. Whatever is printed is fine but the count should not be incorrect i.e. there shouldn't be any missed updates.

So, it is ok even if the print statement does not print exactly 25000 (because the threads are still running). But it will print whatever is the right count at that point of time.

Your point is correct that 25000 may still not be printed but that is not an issue here.

-Paul.

Re: About Question enthuware.ocpjp.v11.2.3654 :

Posted: Sat May 20, 2023 4:47 pm
by edufin166@yahoo.com
this question is not clear.

LEt me give a suggestion:
Use this text alternative...
The code should use AtomicInteger instead of int for count variable to make it thread safe, AND count.incrementAndGet() instead count++;

As the question is, the code is broken.

Of course, the answer is explaining, but AFTER.