About Question enthuware.ocpjp.v17.2.3738 :

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

Moderator: admin

Post Reply
Badem48
Posts: 29
Joined: Thu Aug 24, 2023 4:33 pm
Contact:

About Question enthuware.ocpjp.v17.2.3738 :

Post by Badem48 »

The code snippet provided creates two threads that repeatedly increment three pairs of variables and then check if those pairs are unequal.

Concerns with Provided Answer:
The answer marked as correct is option B, stating that one cannot be certain whether any of the letters i, j, and k will be printed. However, this appears to be incorrect based on the code's behavior:

1. Pair (i1, i2) and (k1, k2): These variables are incremented inside synchronized blocks. The synchronization guarantees that both variables in each pair are incremented atomically, ensuring that the values of i1 and i2, and k1 and k2, are always equal. Thus, the letters "i" and "k" will never be printed.

2. Pair (j1, j2): These variables are incremented outside synchronized blocks, creating a race condition. As a result, the values of j1 and j2 might be unequal, and the letter "j" may be printed.

Option D, "One can be certain that the letters i and k will never be printed during execution," is the correct answer, as it aligns with the code's behavior.

The provided explanation seems to misinterpret the effect of the synchronized blocks, suggesting that the monitors' acquisition does not protect the atomic nature of the operations. However, the synchronized blocks do indeed ensure atomicity for the variables they protect, contrary to what the explanation implies.

I kindly suggest reviewing the given question and its explanation to ensure alignment with the code's actual behavior. The correct answer appears to be option D, and the current marking may lead to confusion among readers seeking to understand these important concepts in multithreading.

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

Re: About Question enthuware.ocpjp.v17.2.3738 :

Post by admin »

No, what you are saying is incorrect.

The issue is whether second thread can read the value of i1 and i2 while the first thread has already performed i1++ but has not yet performed i2++.

The second thread does not synchronize on the same lock that the first thread uses, so the second thread can read the value of i2 anytime irrespective of what the first thread is doing. It is not going to wait for the first thread to finish its synchronized block. So, the second thread may see i1 != i2 and print "i".

raphaelzintec
Posts: 167
Joined: Sun Apr 21, 2024 10:43 am
Contact:

Re: About Question enthuware.ocpjp.v17.2.3738 :

Post by raphaelzintec »

This is not the correct answear: One cannot be certain whether any of the letters i, j and k will be printed during execution
-> We can, run as many times as you want you will only see j

So the correct answear is: One can be certain that the letters i and k will never be printed during execution.
-> Run as many time as you want you won't never see i and k

Because j is the only not being synchronized so it will always be true in if

raphaelzintec
Posts: 167
Joined: Sun Apr 21, 2024 10:43 am
Contact:

Re: About Question enthuware.ocpjp.v17.2.3738 :

Post by raphaelzintec »

Hello ive spend more time analyzing this code, this topic comments, and so on.

The options are very ambiguous.

Options:
- One can be certain that the letter k will never be printed during execution.
= this is a correct option, k will never be printed
- One can be certain that the letters i and k will never be printed during execution.
= this is a correct option, i & k will never be printed

- One cannot be certain whether any of the letters i, j and k will be printed during execution.
= this option is not clear at 100%, id rather say: One can be certain that the letters i and k will never be printed during execution BUT j may be printed.

it's just my personal opinion

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

Re: About Question enthuware.ocpjp.v17.2.3738 :

Post by admin »

Yes, that might be more precise. More importantly, if you understand the behavior of the program correctly now, the question has served its purpose.

raphaelzintec
Posts: 167
Joined: Sun Apr 21, 2024 10:43 am
Contact:

Re: About Question enthuware.ocpjp.v17.2.3738 :

Post by raphaelzintec »

yes thank you

Post Reply

Who is online

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