14

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
  • 778
  • 5
  • 11
  • 4
    Have you read Brian Goetz's Java Concurrency in Practice? He covers the implicit vs explicit lock debate nicely there. – Martijn Verburg Nov 21 '12 at 23:49
  • @MartijnVerburg - Sadly no but I have huge respect for his work. – OldCurmudgeon Nov 22 '12 at 00:29
  • 1
    synchronized keyword may be usefull with simple static methods that should be thread safe, for anything else i would use concurrent. But this is my opinion – Kemoda Nov 22 '12 at 10:21

1 Answers1

12

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 is definitely no.

The wait / notify 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: http://docs.oracle.com/javase/1.5.0/docs/guide/javadoc/deprecation/deprecation.html

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,180
  • 6
  • 64
  • 87
  • Actually, as far I recall, according to the excellent “Java concurrency in practice” book, the `java.util.concurrent` util classes are actually faster. Behind the scenes these classes directly talk to the VM, where as synchronized installs a blunt lock on object in the object graph and thus impacts global performance. – akuhn Nov 24 '12 at 04:37
  • Forgive me @Stephen if I came across as suggesting that we actually remove `synchronized` et. al. I am merely suggesting deprecation, which really only says don't use this for new code. I wouldn't dream of suggesting damaging tried and tested legacy code my demanding their removal. – OldCurmudgeon Nov 24 '12 at 20:09
  • @OldCurmudgeon - rather a late response, but I think deprecation is too extreme. 1) It means that the feature *could* be removed. 2) It implies that the feature is broken, as distinct from merely being old-fashioned. 3) A lot of people are still happy to write new code that way ... and there's no strong reason that they shouldn't. 4) There are other, less "in your face" ways to discourage it; e.g. writing PMD rules ... – Stephen C Feb 01 '13 at 12:28
  • @StephenC - Is there then a slightly less dramatic action we can take that will eventually result in them not being used or taught in college. They clearly should be avoided. I suspect PMD rules - although a good idea - would not reach the teachers very quickly. – OldCurmudgeon Feb 01 '13 at 13:19
  • 1
    @StephenC A nitpick: going by the Java docs you linked to, I don't think deprecation means the deprecated code is broken. That's one reason, but as the docs says, an API can be deprecated when it's superseded by a newer, better API (as, the OP argues, is the case with concurrency). And low-level concurrency, if not actually encouraging bad practices, is certainly _very_ error prone. – Andres F. Feb 01 '13 at 16:33
  • @AndresF - nitpicks noted. While low-level concurrency is error prone, there are situations where the high-level libraries don't cut it. And error prone does not mean erroneous. It is not *that hard* to write provably correct code using the low-level facilities. – Stephen C Feb 02 '13 at 02:52
  • @OldCurmudgeon - I'm afraid that deprecation would make little difference to lecturers who don't update their lecture notes. (And the ones who are on top of this are likely to teach their students about FindBugs too.) The real problem is that most CS lecturers aren't software engineers, and don't have the experience to know what is going to actually work in large-scale software development. – Stephen C Feb 02 '13 at 02:57
  • Deprecation doesn't force anyone to change any old code, so I don't see the problem. – Konrad Höffner Nov 03 '16 at 18:57
  • @KonradHöffner - That is technically true. However, if you recompile code and you see new Deprecation warnings, then you *ought* to check up on why. Often you will find that it is *advisable* to change your code. (And if you are recommending that people ignore deprecation warnings as a matter of course, check the context as per the Question. The whole point of deprecating `wait()` and `notify()` would be to encourage people to stop using them ... because using them is objectively harmful in some way._ ) – Stephen C Nov 05 '16 at 03:43