jQuery in Action, 2nd edition*
The moose likes Threads and Synchronization and the fly likes Synchronized blocks vs java.util.concurrent.locks Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of OCA/OCP Java SE 7 Programmer I & II Study Guide this week in the OCPJP forum!
JavaRanch » Java Forums » Java » Threads and Synchronization
Bookmark "Synchronized blocks vs java.util.concurrent.locks" Watch "Synchronized blocks vs java.util.concurrent.locks" New topic
Author

Synchronized blocks vs java.util.concurrent.locks

Kalyan Anand
Ranch Hand

Joined: Feb 07, 2007
Posts: 194
Are there any cases where we still need to use the synchronized block or method and can it be assumed that synchronized keyword is no longer needed in programming ?
Jesper de Jong
Java Cowboy
Saloon Keeper

Joined: Aug 16, 2005
Posts: 14280
    
  21

Originally posted by Santhosh Jali:
... and can it be assumed that synchronized keyword is no longer needed in programming ?

No, you cannot assume that the synchronized keyword is no longer needed. Why do you think it is no longer needed? The classes in the package java.util.concurrent were not meant to make the synchronized keyword obsolete.


Java Beginners FAQ - JavaRanch SCJP FAQ - The Java Tutorial - Java SE 8 API documentation
Kalyan Anand
Ranch Hand

Joined: Feb 07, 2007
Posts: 194
I see that whatever synchronized is used for the same can be programmed using the concurrency API so where do you see the need for the keyword ?
Jeff Langr
author
Ranch Hand

Joined: May 14, 2003
Posts: 762
It's actually a good question. I remember reading someone from Sun recommending the continued use of synchronized in circumstances where it was sufficient. In other words, their implication was that the new lock mechanism was more flexible but also more complex, and thus one should only use it if one needed the additional flexibility.

You might read the javadoc for java.util.concurrent.locks.Lock for some additional insights.

Jeff


Books: Agile Java, Modern C++ Programming with TDD, Essential Java Style, Agile in a Flash. Contributor, Clean Code.
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18917
    
  40

Originally posted by Santhosh Jali:
I see that whatever synchronized is used for the same can be programmed using the concurrency API so where do you see the need for the keyword ?


None. There are no places where the synchronized keyword can be used but the reentrant lock class cannot. However, with the synchronized keyword, you don't have to create an instance (which later has to be GC'ed), use try-finally to ensure locks are released with exceptions, or make sure that all locks and unlocks are balanced.

You can make the argument that synchronized methods are obsolete because you can use synchronized blocks for every case, that the while loop is obsolete because you can use for loops for every case, etc. This can be considered the same here.

Henry


Books: Java Threads, 3rd Edition, Jini in a Nutshell, and Java Gems (contributor)
Mike Simmons
Ranch Hand

Joined: Mar 05, 2008
Posts: 3018
    
  10
[Henry]: There are no places where the synchronized keyword can be used but the reentrant lock class cannot.

The only exception I can think of is if you've got a system where part of the code (outside your control) is already designed to require external synchronization (sync blocks) for safe use. An example is found in Collections.synchronizedList() and similar methods. "It is imperative that the user manually synchronize on the returned list when iterating over it." (Not to mention manually synchronizing for any other action involving two or more successive method calls which must not be disrupted in between calls, e.g. getting the first element if the size is not zero, or accessing the last element in the list.) My point is, replacing synchronization with a concurrent lock will not work here, since you can't alter the code in java.util.Collections (well, not without some very unusual hacking), That code uses sync locks internally, and expects external code to do the same when internal synchronization is not enough (as often happens for this API). External code cannot simply use concurrent util locks instead of sync locks and expect one type of lock to interact well with the other. They're like two separate, parallel systems - they provide similar functionality, but they aren't directly interchangeable at a low level. Once part of a program is designed to depend on sync blocks for safe access to a particular class, the rest of the program must follow suit when accessing that class. Likewise for java.util.concurrent locks.
Kalyan Anand
Ranch Hand

Joined: Feb 07, 2007
Posts: 194
Originally posted by Jeff Langr:
I remember reading someone from Sun recommending the continued use of synchronized in circumstances where it was sufficient.

Correct me if I get it wrong. Synchronized keyword is the preferred way unless we have the need to use the flexibilities offered by the API like chained locking or others.
Jeff Langr
author
Ranch Hand

Joined: May 14, 2003
Posts: 762
Originally posted by Santhosh Jali:

Correct me if I get it wrong. Synchronized keyword is the preferred way unless we have the need to use the flexibilities offered by the API like chained locking or others.


That was my understanding. Sun has no intent of deprecating the synchronized keyword. If it works for you, prefer the simpler mechanism.

Jeff
 
Consider Paul's rocket mass heater.
 
subject: Synchronized blocks vs java.util.concurrent.locks