The last time I checked the actual byte code was different ...
The first had the byte code for entering the monitor, the second set the ACC_SYNCHRONIZED flag on the method, the effect may be the same but literally they are different, I wouldn't look at the byte code for that reason as it could confuse the issue. You could argue synchronized method is more efficient but I wouldn't get obsessed about it but if your intent is to synchronize the whole method I would definitely do that as its clearer.
Krishna Chhabra wrote:Not able to understand exactly that what does (this) means in below code
It's telling us which lock we're going to obtain. The only thing that the synchronized keyword does¹ is to obtain the lock for the indicated object, blocking at that point in its execution until the lock is released if some other thread currently hodls it. That's all. When we do synchronized (this) that just means we're obtaining the lock for the "current" object.
¹Actually that's all it does in terms of mutual exclusion. It also provides some memory barrier effects for consistency and predictability of the values of shared variables, but that part isn't pertinent to your question.
You won't notice any difference until you have other synchronised blocks. Look at the foo() method.When you enter the bar() method, the lock bit on amount (assuming it has been initialised, otherwise it will throw a null pointer exception) is set, and the thread whence the bar() method is called can run normally. Meanwhile another thread can access foo() and thence any other blocks synchronised on this. Whichever thread enters foo() sets the lock bit on this and claims ownership of it. But it is possible for different threads to execute foo() and bar() simultaneously.Now whichever thread executes either of those methods will set and claim ownership of the lock on this; it is only possible for one thread to execute those methods at once. Only the same thread can go from bar() to foo() or vice versa. That would happen if the two methods call each other.
If you reassign amount from either method, who knows what will happen.
Dhananjaykumar Kushwaha wrote:. . . Q 38 of practice book . . .
Which book? Please always give full details of sources for all such material, at least authors and book title. Page numbers are very useful, too.
Is that the original question, or what you modified? What else did the question say; there is always more than the code.
That is very different from what you posted yesterday. But if you only have one instance of PQ38, you aren't going to notice the difference.
. . . So why i am get unpredicted result.
Result were : -5 , 0 , 5, 10
When I tried your code on JShell, I got various results, but none of them positive. I am not sure, but I think you will get problems if the same thread is executed in line 25 and in line 24. If they are different, it will be impossible for line 25 to be executed until after line 24 and the associated method call have completed. But if they are executed on the same thread, it is possible for the withdraw() method to start before deposit() has completed; since += and -= are not atomic operations on an Integer. (I don't think they are atomic operations on an int, but I am not certain.)
So, if thread₂₈ happens to execute both lines 24 and 25, there is a risk that the withdraw() method will run before the “new” value from deposit() is visible, so you can expect to get “wrong” values occasionally, and your 9999 iterations mean it is likelier than not that such a race condition will occur at some point giving rise to a wrong result.
Please show us the original question, so we can see what you changed.
Line 16 shows you setting the monitor, line 17 shows which object you are using as the monitor, and line 24 shows the monitor being released. I am not sure what lines 26‑29 30 do.
[Edit] change line numbers; I am quoting the numbers on the left not the right.
You showed up just in time for the waffles! And this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop