Is "Every object being available for locking" an anti-pattern?

Question

Stumble upon the accepted answer to this question: https://stackoverflow.com/questions/186964/java-core-api-anti-patterns-what-is-wrong/891589#891589 that mentions:

Every object being available for locking instead of specific lock objects(.NET has the same problem)

Why is it an anti-pattern?

Or in another word:

How to prove that there is an anti-pattern in the statement?
How to prove that there is not an anti-pattern in the statement?

I don't know about 'anti-pattern' but when Per Brich Hansen saw Java's `wait()` and `notify()` he commented 'clearly I have laboured in vain'. — user207421, Jan 05 '14 at 09:15
I also don't know what you mean by 'prove that there is [/is not] an anti-pattern'. Design Patterns is a qualitative discipline, to put it mildly. There are no axioms, or theorems, or proofs. — user207421, Jan 05 '14 at 09:22
@EJP Could you say which pattern the statement violates and the reason? Or no design pattern is violated at all? — , Jan 05 '14 at 09:28
No I can't. Nobody can. The question betrays a complete lack of understanding. An 'anti-pattern' isn't a 'violation of a pattern'. There is no such thing. An anti-pattern is just a design pattern of its own, but which is a bad idea instead of a good idea. This sort of thing just further exposes the formal limitations of DP: you can only express a truth about DP in the form of another DP, and there is no logical calculus of DPs. If you want to know what's wrong with wait/notify I suggest you read Per Brich Hansen's paper. Google will find it. But don't expect it to be written as a DP. — user207421, Jan 05 '14 at 12:17
Don't deface your question, doing so repeatedly will get your account suspended. Edits are meant to improve a question, not to hide its previous content - which you can't do anyways as the revision history is accessible to everyone. — l4mpi, May 27 '14 at 20:23

score 4 · Accepted Answer · edited May 23 '17 at 10:32

I don't know what that person meant exactly, but one side effect is that you can write this:

private final String s = "mutex";
private void m1() { synchronized(s) {} }

private final Boolean b = Boolean.FALSE;
private void m2() { synchronized(b) {} }

It looks like these methods are using private, non shared locks. But Strings are interned so another code using "mutex" as a mutex would actually be using the same lock, which can easily lead to deadlocks. Similarly, Boolean.FALSE can be accessed from alien code causing the same issue.

See also: Problem with synchronizing on String objects?

Is "Every object being available for locking" an anti-pattern?

1 Answers1