• Post Reply Bookmark Topic Watch Topic
  • New Topic

Synchronized method, or multiple synchronized blocks  RSS feed

 
Cameron Dalton
Greenhorn
Posts: 19
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I find myself writing a method that requires multiple synchronized() blocks within the method. I'm looking for some opinions here. Is it better to:

- synchronize the entire method (to have fewer synchronizations), or
- synchronize many times within the method (to have less code synchronized and reduce the scope of synchronization)

I believe performance will be better with just the single synchronization due to overhead involved with acquiring the lock, like flushing the memory cache. But it is also best practice to keep the scope of synchronization as small as possible to help guard against deadlock. I think I'm leaning one way more than the other, but what do you all think?

Thanks for your input.
 
Chris Hurst
Ranch Hand
Posts: 443
3
C++ Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Assuming your not Doug Lea etc and your sync-ing on the same object and your not writing some cutting edge real time library, assuming your on a modern JVM ...

Keep it simple , nice small synchronized methods , profile your app later and get a bit flash at the end if performance requires it.

Obviously this advice could lead to some really bad code if you've just extended your sync block over an operation that didn't need to be sync'ed and it consumes a large amount of run time so use common sense just no micro optimisations early on.

I've inherited a lot of code where people try to get very sparse with synchronization but don't seem to have a clue about happens before ordering etc and it usually turns into gibberish ie even if your clever enough to do it will the guy maintaining your code know what your doing.

I wouldn't worry about memory flushes and lock acquisition too much (again except in extreme performance circumstance in which case you should be looking at all the new Java 5 stuff (read / write locks etc) anyway) as their cost on their own can be negligible to nothing (eg see JVM theoretical optimisations lock coarsening, lock ellision, adaptive locking etc etc etc ) ie 'in theory' memory flushes aren't strictly mandatory on sync blocks just if needed to maintain happens before ordering (in theory) etc ie memory barriers are a side effect.

I've personally found dead locks not that much of a problem in simple sync'ed programs, though if you write some bad code with respect to happens before ordering that can be a nightmare ie you've under synchronized, I find over synchronized apps much easier to fix than under sync'ed ones. Small sync'ed blocks in methods are a nice way of hiding the fact a lock is acquired particularly with no methods comments and can actually help get you some deadlock when a calling method acquires a lock without realising ie when you synchronize the method its very obvious from the interface.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!