• Post Reply Bookmark Topic Watch Topic
  • New Topic

Synchronized Block & Method  RSS feed

 
Vijay Kumar
Ranch Hand
Posts: 260
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi..
Please tell me whate is the difference if I synchronized a block & method.
Thanks
 
Poobhathy Kannan
Ranch Hand
Posts: 94
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
As far as I know, nothing difference.
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well, a synchronized block allows more flexibility and control. You can (and must) choose exactly what object you will use as the monitor, and you can choose where the block begins and where it ends. With a synchronized method, the monitor is always the current instance "this" (or the Class instance for a static method), and the sync must begin at the start of the method, and end at the end. Other than that, they work the same way. There is no functional difference between

and
 
Sanjeev Singh
Ranch Hand
Posts: 381
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
As far as I know, nothing difference.

Then why they are two?
 
Peter Chase
Ranch Hand
Posts: 1970
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Basically, synchronized blocks can do everything you need.

Synchronized methods are purely a convenience, for situations where the whole content of a method would otherwise be enclosed in a synchronized block, using the instance (or class, if static). Generally, such a synchronized block would result in identical bytecode as the synchronized method, so there is no semantic or performance difference at all.

Apart from brevity, a nice thing about synchronized methods is that the fact that it's synchronized appears in the Javadoc.
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Making a method synchronized has no effect on the javadoc - see Vector for an example. It's considered an implementation detail, not part of the public API.

I think synchronized methods were included in order to make synchronization appear simple to programmers. I believe this was a mistake, as it seems to me that many Java programmers seem to think that "synchronized" automatically means "thread-safe" and do not pay adequate attention to which object is being used as a monitor. Also I typically favor synchronizing on privately-held objects in order to limit the possibility that outside code may inadvertently create deadlock by syncing on some object they shouldn't have. This is not possible with synchronized methods, since the monitor is necessarily the current instance, already visible to any code which is invoking the method. I think we'd have been better off if only synchronized blocks were allowed, so that people would always see exactly what object is being used as monitor in each case. Too late now though...
 
Mr. C Lamont Gilbert
Ranch Hand
Posts: 1170
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Never use synchronized methods. They expose their synchronization object to the outside world which violates OO principles. And will burn you...
 
Peter Chase
Ranch Hand
Posts: 1970
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Jim Yingst:
Making a method synchronized has no effect on the javadoc


Oh. Serves me right for writing without checking first. Apologies.

I still kinda like synchronised methods sometimes for quick n' dirty code. But I suppose it is probably the wrong thing to do really.
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Mr. C Lamont Gilbert:
Never use synchronized methods. They expose their synchronization object to the outside world which violates OO principles. And will burn you...


It will only burn you if someone *makes use of* the exposed synchronization object. So it could be argued that that's the real culprit.
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ilja - sure, but you could say the same thing about private data, couldn't you? Why not just make it all public?
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Jim Yingst:
Ilja - sure, but you could say the same thing about private data, couldn't you? Why not just make it all public?


I'm not sure that a language that only had public data would be problematic for a disciplined team. Although I'd probably prefer a language where it always is private, such as Smalltalk.

In Java, though, making it public doesn't give you any benefit I could see. Synchronized methods, though, could be argued to lead to a little bit less complex code.

I'd also say that it's not really using synchronized methods which exposes the synchronization object, but synchronizing on "this" in general - which synchronized methods are only a special case of.
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
[Ilja]: I'm not sure that a language that only had public data would be problematic for a disciplined team. Although I'd probably prefer a language where it always is private, such as Smalltalk.

Agreed on both counts. I can't usually assume that other programmers will behave in what I would consider a properly disciplined manner. So I like it when the language reinforces good behavior, and protects against bad behavior.

[Ilja]: In Java, though, making it public doesn't give you any benefit I could see. Synchronized methods, though, could be argued to lead to a little bit less complex code.

Less complex looking, yes, but considering that there seem to be many people with no idea what a monitor is, or how static synchronized methods interact with nonstatic synchronized methods, I don't see the apparent simplicity of synchronized methods as all that helpful.

[Ilja]: I'd also say that it's not really using synchronized methods which exposes the synchronization object, but synchronizing on "this" in general - which synchronized methods are only a special case of.

Agreed. But synchronized methods force you to use "this", so that's a big point against them as far as I'm concerned. If synchronized methods did not exist, then I would campaign against synchronized blocks using "this". As it is though, I think it's more useful to concentrate on the most common offenses, from people who use synchronized methods.
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Jim Yingst:

Less complex looking, yes, but considering that there seem to be many people with no idea what a monitor is, or how static synchronized methods interact with nonstatic synchronized methods, I don't see the apparent simplicity of synchronized methods as all that helpful.


Well, to the amount that I have such people on my team, I prefer teaching over safeguarding. (Which doesn't mean that I'm totally against safeguarding, mind you.) And to the amount that they are on other people teams - well, I don't really care that much...

Seriously, I can understand everyone who prefers to not use synchronized methods. I just think that there are several forces at play, forces that could make using synchronized methods the right choice for some teams, too. So it's the (perceived over-) generalization I'm disagreeing with.
 
Don't get me started about those stupid light bulbs.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!