18

Is there a single scenario (other than compatibility with ancient JVMs) where using synchronized is preferable to using a Lock? Can anyone justify using wait or notify over the newer systems?

Is there any algorithm that must use one of them in its implementation?

I see a previous questions that touched on this matter but I would like to take this a little further and actually deprecate them. There are far too many traps and pitfalls and caveats with them that have been ironed out with the new facilities. I just feel it may soon be time to mark them obsolete.

Community
  • 1
OldCurmudgeon
  • 818

2 Answers2

15

Is there any algorithm that must use one of them in its implementation?

Almost certainly not. (Indeed, from the theoretical perspective, you should be able to simulate wait / notify using other java.util.concurrent.. classes. And synchronized could be replaced with explicit Lock operations ... though you would need to be careful to unlock in finally clauses.)

However, there are probably algorithms where the best performing implementation in Java involves direct use of synchronized, with or without wait and notify.

Is it time to deprecate synchronized, wait and notify?

Irrespective of the answer to the previous question, the answer to this is definitely "No" ... IMO.

The wait and notify methods can be (and often are) used correctly. In Java, deprecation is reserved for classes and methods that are broken; i.e. where continued use should be corrected as a matter of urgency. If Sun (and now Oracle) deprecated something as fundamental and as widely used as wait/notify, they would be creating a serious compatibility problem for huge amounts of legacy code. That is NOT in anyone's interest.

If you want to get rid of synchronized / wait / notify in your code, that is fine. But deprecation calls for the rewriting of large amounts of essentially correct multi-threaded code, and that would be a BAD IDEA. Corporate IT managers and software product managers would hate you for suggesting it ...

It is worth reading what "deprecated" means according to the Java documentation: https://docs.oracle.com/en/java/javase/21/core/deprecation-jdk.html. Starting in Java 9, they make a distinction between simple "deprecation" and "deprecation for removal".

And also note that we are talking about deprecating stuff that is core to the Java language. Deprecating synchronized has huge consequences.

Stephen C
  • 25,388
  • 6
  • 66
  • 89
-2

In objective-c, @synchronized makes trivial cases of exclusive operations trivial to write. It is also highly time efficient because the implementation checks if there would be non-contested locks involved, and space efficient because it relies on a small number of underlying locks. In Swift it is not part of the language, but can easily be implemented once with about ten lines of code.

Deprecating this would be absolutely counter productive.

Sorry if Java can’t or doesn’t produce an efficient implementation.

gnasher729
  • 49,096