Why did Java and C# add intrinsic lock to every ob

Question

Making every object lockable looks like a design mistake:

1. You add extra cost for every object created, even though you'll actually use it only in a tiny fraction of the objects.
2. Lock usage become implicit, having lockMap.get(key).lock() is more readable than synchronization on arbitrary objects, eg, synchronize (key) {...}.
3. Synchronized methods can cause subtle error of users locking the object with the synchronized methods
4. You can be sure that when passing an object to a 3rd parting API, it's lock is not being used.

eg

class Syncer {
    synchronized void foo(){}
}
...
Syncer s = new Syncer();
synchronize(s) {
    ...
}
// in another thread
s.foo() // oops, waiting for previous section, deadlocks potential

1. Not to mention the namespace polution for each and every object (in C# at least the methods are static, in Java synchronization primitives have to use await, not to overload wait in Object...)

However I'm sure there is some reason for this design. What is the great benefit of intrinsic locks?

Answer 1

One benefit is automatic unlock on exit from synchronized block, even by exception.

Answer 2

I assume that like toString(), the designers thought that the benifits outweighed the costs.

Lots of decisions had to be made and a lot of the concepts were untested (Checked exceptions-ack!) but overall I'm sure it's pretty much free and more useful than an explicit "Lock" object.

Also do you add a "Lock" object to the language or the library? Seems like a language construct, but objects in the library very rarely (if ever?) have special treatment, but treating threading more as a library construct might have slowed things down..

Answer 3

You add extra cost for every object created, even though you'll actually use it only in a tiny fraction of the objects.

That's determined by the JVM implementation. The JVM specification says, "The association of a monitor with an object may be managed in various ways that are beyond the scope of this specification. For instance, the monitor may be allocated and deallocated at the same time as the object. Alternatively, it may be dynamically allocated at the time when a thread attempts to gain exclusive access to the object and freed at some later time when no thread remains in the monitor for the object."

I haven't looked at much JVM source code yet, but I'd be really surprised if any of the common JVMs handled this inefficiently.

Lock usage become implicit, having lockMap.get(key).lock() is more readable than synchronization on arbitrary objects, eg, synchronize (key) {...}.

I completely disagree. Once you know the meaning of synchronize, it's much more readable than a chain of method calls.

Synchronized methods can cause subtle error of users locking the object with the synchronized methods

That's why you need to know the meaning of synchronize. If you read about what it does, then avoiding these errors becomes fairly trivial. Rule of thumb: Don't use the same lock in multiple places unless those places need to share the same lock. The same thing could be said of any language's lock/mutex strategy.

You can be sure that when passing an object to a 3rd parting API, it's lock is not being used.

Right. That's usually a good thing. If it's locked, there should be a good reason why it's locked. Other threads (third party or not) need to wait their turns.

If you synchronize on myObject with the intent of allowing other threads to use myObject at the same time, you're doing it wrong. You could just as easily synchronize the same code block using myOtherObject if that would help.

Not to mention the namespace polution for each and every object (in C# at least the methods are static, in Java synchronization primitives have to use await, not to overload wait in Object...)

The Object class does include some convenience methods related to synchronization, namely notify(), notifyAll(), and wait(). The fact that you haven't needed to use them doesn't mean they aren't useful. You could just as easily complain about clone(), equals(), toString(), etc.

Answer 4

Actually you only have reference to that monitor in each object; the real monitor object is created only when you use synchronization => not so much memory is lost.

The alternative would be to add manually monitor to those classes that you need; this would complicate the code very much and would be more error-prone. Java has traded performance for productivity.