About Question enthuware.ocpjp.v11.2.3654 :

Help and support on OCA OCP Java Programmer Certification Questions
1Z0-808, 1Z0-809, 1Z0-815, 1Z0-816, 1Z0-817

Moderator: admin

Post Reply
aPerson
Posts: 17
Joined: Fri Aug 12, 2022 10:19 am
Contact:

About Question enthuware.ocpjp.v11.2.3654 :

Post 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?

admin
Site Admin
Posts: 10036
Joined: Fri Sep 10, 2010 9:26 pm
Contact:

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

Post 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!
If you like our products and services, please help us by posting your review here.

aPerson
Posts: 17
Joined: Fri Aug 12, 2022 10:19 am
Contact:

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

Post 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?

admin
Site Admin
Posts: 10036
Joined: Fri Sep 10, 2010 9:26 pm
Contact:

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

Post 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.
If you like our products and services, please help us by posting your review here.

edufin166@yahoo.com
Posts: 24
Joined: Wed Sep 28, 2022 9:41 am
Contact:

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

Post 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.

Post Reply

Who is online

Users browsing this forum: Bing [Bot] and 65 guests