• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Paul Clapham
  • Ron McLeod
  • Bear Bibeault
  • Liutauras Vilda
Sheriffs:
  • Jeanne Boyarsky
  • Junilu Lacar
  • Henry Wong
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Jj Roberts
  • Tim Holloway
  • Piet Souris
Bartenders:
  • Himai Minh
  • Carey Brown
  • salvin francis

synchronized (this) means?

 
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

Not able to understand exactly that what does (this) means in below code



Thanks
 
Ranch Hand
Posts: 199
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

The literates say that synchronize(this) inside a method is exactly the same that synchronize the method

because the synchronization in the 2 cases is over the object instance.

I would check now this with a class bytecode dump (just for fun),

Best regards,

 
Ranch Hand
Posts: 443
3
Eclipse IDE C++ Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.

See a more detailed explanation below ...

http://stackoverflow.com/questions/9117115/why-synchronized-keyword-does-not-create-monitor-enter-every-time
 
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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.
 
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Can anybody give me difference between

public void bar() {
   synchronized (this) {
     // body
   }
 }


and

Integer amount ;

public void bar() {
   synchronized (amount) {
     // body
   }
 }
 
Marshal
Posts: 71025
291
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Actually, I had modified the question of concurrency Q 38 of practice book




It gives unpredicted result. Since I had use synchronized the cookies so if i am using it no other mehtod can use it. So why i am get unpredicted result.

Result were : -5 , 0 , 5,  10
 
Campbell Ritchie
Marshal
Posts: 71025
291
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Sorry for delay; the site has been “down”.

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.

I may be better to say “monitor” than ”lock”.
 
Dhananjaykumar Kushwaha
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Actually, I had modified from the book Java® SE 8 Programmer practice test Scott Selikoff, Jeanne Boyarsky Chapter 20 Java Concurrency Q38.

Actually we have used synchronized

so it lock the cookies variable by using monitor of java bytecode .
My question is why it predicate different result since we are using synchronized keyword ?

You are right += and -= are not atomic operations but i am using under synchronized so it must be atomic.

I am not good in bytecode may be it help you in finding the solution
 
Campbell Ritchie
Marshal
Posts: 71025
291
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
WHAT is your favorite color? Blue, no yellow, ahhhhhhh! Tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
https://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton
reply
    Bookmark Topic Watch Topic
  • New Topic