• 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 Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Synchronized blocks vs java.util.concurrent.locks

 
Ranch Hand
Posts: 194
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 ?
 
Java Cowboy
Posts: 16084
88
Android Scala IntelliJ IDE Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
Kalyan Anand
Ranch Hand
Posts: 194
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 ?
 
author
Posts: 799
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
author
Posts: 23951
142
jQuery Eclipse IDE Firefox Browser VI Editor C++ Chrome Java Linux Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
 
Master Rancher
Posts: 4806
72
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
[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
Posts: 194
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 799
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
 
reply
    Bookmark Topic Watch Topic
  • New Topic