Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share|improve this question
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 0: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
add comment

2 Answers 2

up vote 6 down vote accepted

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.

share|improve this answer
    
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 4: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 1 '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 1 '13 at 13:19
    
@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 1 '13 at 16:33
show 2 more comments

In my humble opinion, yes.

And other language communities would probably do so and remove these methods from the language. However, I doubt that the Java community would appreciate such a move. Each language community has different values, and as it happens one of the core values of the Java community is to favor backward-compatibility over breaking changes.

In addition to that, communities go through a life cycle which is best described by drawing an analogy to the four seasons.

  • In the Spring phase, when a community is new, it is very vibrate and eager for innovation. A spring community is most likely driven by early adopters and people who are generally unhappy with current solutions (because they do not fit their novel business needs) who are looking for new ways of getting things done.

  • As a technology becomes more popular it moves into the Summer phase, which is a time of consolidation and settling down. By now the community will be probably very popular and getting a lot of industry attention. But also, it will have settled on its proven ways of doing things and most likely having found a killer application for its technology which drives the community. Innovation is no longer a driver.

  • However, as a result of all this the community will become less agile and other communities and technologies will start finding innovative niches and at some point the community might lose more and more bright minds to other rising communities and thus enter the Autumn phase.

  • Which is followed by Winter, when a technology has become legacy and the community is virtually dead …

Java is currently transitioning from autumn to winter. Five years ago people fought whether to add closures to Java or not. Today they couldn't care less. Everybody is doing Closure, Ruby and Javascript anyway. So, no, they'll never deprecate synchronized because, honestly, who cares about deprecating pieces of a technology that's deprecated as a whole anyway?

My 5 cent.

share|improve this answer
2  
I downvoted you, because I think you don't answer the question ("Is Lock always preferable to synchronized ?") –  barjak Feb 1 '13 at 14:33
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.