0

I believe I've seen the expressions "own a monitor", and "own a lock". I'd like to verify that only a monitor can be "owned". And that a lock is "acquired", not owned. If that's wrong, I'd appreciate the correct usage of "own" and "acquire", in the context of Java multithreading.

Julian A.
  • 10,928
  • 16
  • 67
  • 107
  • 1
    I think owning a lock internally leads to owning the monitor of the lock in question. I have been using them interchangeably. Not sure if it makes any difference. – Tirath Mar 11 '16 at 06:36

2 Answers2

6

A lock is kind of data which is logically part of an object’s header on the heap memory. Each object in a JVM has this lock (or mutex) that any program can use to coordinate multi-threaded access to the object. If any thread want to access instance variables of that object; then thread must “own” the object’s lock (set some flag in lock memory area). All other threads that attempt to access the object’s variables have to wait until the owning thread releases the object’s lock (unset the flag).

Once a thread owns a lock, it can request the same lock again multiple times, but then has to release the lock the same number of times before it is made available to other threads. If a thread requests a lock three times, for example, that thread will continue to own the lock until it has “released” it three times.

Monitor is a synchronization construct that allows threads to have both mutual exclusion (using locks) and cooperation i.e. the ability to make threads wait for certain condition to be true (using wait-set).

In other words, along with data that implements a lock, every Java object is logically associated with data that implements a wait-set. Whereas locks help threads to work independently on shared data without interfering with one another, wait-sets help threads to cooperate with one another to work together towards a common goal e.g. all waiting threads will be moved to this wait-set and all will be notified once lock is released. This wait-set helps in building monitors with additional help of lock (mutex).

enter image description here

  • "If any thread want to access instance variables of that object; then thread must “own” the object’s lock". Well, it would be up to you as the developer to enforce that (by using `synchronized` blocks). Thread-safety is not managed by the JVM for you, so you can read instance fields without any locks if you feel like it, and in many situation it is not necessary to take out locks (or sufficient to use more coarse-grained locks). – Thilo Mar 12 '16 at 00:02
1

If a lock is not shared (i.e. can be acquired only once), then whoever holds the single lock currently is the "owner" of the lock.

In the case of a synchronized block, only one Thread is allowed to acquire the lock at the same time (that's the whole purpose here). So that Thread will "own the lock".

Thilo
  • 257,207
  • 101
  • 511
  • 656
  • Thanks. And what about the monitor? – Julian A. Mar 11 '16 at 07:23
  • 1
    Lock and monitor are pretty much interchangeable terms here. – Thilo Mar 11 '16 at 07:38
  • 1
    @Julian In Java we have locks, which are implemented using monitors which is a component supported by the OS. While all objects have a lock, only those objects use it have a monitor (as each monitor is relatively expensive) – Peter Lawrey Mar 11 '16 at 07:44
  • 1
    @PeterLawrey "... only those objects use it have a monitor" - did you mean to say "only the objects that use it have a monitor"? – Julian A. Mar 11 '16 at 22:54