Java Thread object monitor - where does it fit into the picture

[Ronald Vermeij]

During my study on Java threads, I find many references to a "object monitor".
I have a hard time, trying to fit in the "object monitor" into the complete multi-threaded picture.

So far I have learned the following facts that:
- Every object has its own "monitor"
- A monitor watches over an object / the thread
- A monitor handles access_requests to an object/thread
- A monitor protects an object variable instances /class variable
- A monitor provides a lock to an object
- A monitor has "something to do with synchronization"

Question:
1. Is the "object monitor" a (hidden) part every Java object / thread?
2. Does the "object monitor" belong to the Java Virtual Machine?
3. Do you have an illustration that shows the relation between an object, its monitor and the JVM

[Henry Wong]

In the world of threading, there is a ton of "terminology" baggage. Basically, for some weird reason, terminology gets mixed between the many threading systems. Java didn't help matters any by adding to the terminology mess too. And IMHO, the "monitor" is probably the worst offender. So....


Basically, at the core level, there are two threading terms to be concerned with -- the mutex and the condition variable. The mutex is a mutually exclusive lock, which is a fancy way of saying "something that is guaranteed to only have one owner". To guarantee that a thread is the only one operating on some piece of data, it should grab a mutex assigned for it, do the work, and release the mutex. The mutex will do the work of enforcing the guarantee that there will only be one owner, and hence, guarantee that only one thread will work on the data.

The condition variable allows the ability for the thread to wait for a condition, it also has a mechanism for threads that set the condition to signal the waiting threads. There are also complex race conditions that exist with the assign mutex that the condition variable takes care of. Blah. Blah. Blah... summary -- it is a way for threads to signal each other about a state.

Built upon these basic concepts are a bunch of other concepts... semaphores, reader writer locks, producer consumer, etc. etc. etc.


In Java speak, the mutex is implemented via the synchronization keyword. And the condition variable is implemented via the wait and notify methods. There are also higher level classes that does the same thing, and give more control and functionality.

As for "monitor", that term doesn't seem consistent. In some cases, I have seen it as a synonym for mutex. But, in most cases, it seems to refer to both the mutex and condition variable together.

Henry

[Jim Hoglund]

Thanks Henry . . .

Jim ... ...

[Ronald Vermeij]

Henry Wong wrote:Basically, at the core level, there are two threading terms to be concerned with -- the mutex and the condition variable.

Thank you very much this very elementairy and basic explanation Henry!.
This makes (more) sense to me, since i've studied Andrew S. Tanenbaum Minix Operatings System, back in the good old highschool days. In the Minix OS there were also - only Mutexes (aka semaphores) and StateVariables (aka condition variable). That kept things simple and crystal clear. They are a bit of "low level" control mechanismes, but that's the way i like 'm, the very basics of stuff, the elementairy building blocks without any fancy on top of it. This helps me really to gain insight "how stuff really works under the (Java) hood"

A. The mutex is a mutually exclusive lock, which is a fancy way of saying "something that is guaranteed to only have one owner". To guarantee that a thread is the only one operating on some piece of data, it should grab a mutex assigned for it, do the work, and release the mutex. The mutex will do the work of enforcing the guarantee that there will only be one owner, and hence, guarantee that only one thread will work on the data....... In Java speak, the mutex is implemented via the synchronization keyword.

Understanding by Code-Example :-)

public class SynchronizedCounter {
    private int c = 0;
    public synchronized void increment() {
        c++;
    }
    public synchronized int value() {
        return c;
    }
}

So when some other object/thread calls the SynchronizedCounter.increment() method, this is what really happens "under the hood"

1 - (mutex = down)
The Java Virtual Machine (JVM) Object Manager LOCKS all access to The SynchronizedCounter object.
This guaranties that only 1 calling object,thread now has access to The SynchronizedCounter object.
- All other "SynchronizedCounter calling objects" have to wait on the first object to finish its job.
- They have to wait for the SynchronizedCounter object "Mutex up signal" from the Java Virtual Machine's Object Manager

2 - The JVM switches from "Multi-threading" (of all threads running in memory at the same time) turns into "Single threading" (execution only of the SynchronizedCounter. object/thread)
3 - JVM executes the "SynchronizedCounter.increment() method" code and thereby entering the {synchronized code block}
4 - JVM increments the value in the memory location of [private int C] by 1
5 - JVM exits the "SynchronizedCounter.increment() method" and thereby leaving the {synchronized code block}

6 - (mutex = Up)
The JVM Object Manager UN-LOCKS the SynchronizedCounter object.
7 - JVM switches back from "Single threading" to "Multithreading"
8 - Execution of all threads "continues as usual"

Am i right so far Henry?

[Jim Hoglund]

Good explanation but here is one adjustment. The JVM does not stop other threads.
If this were true there would be no need to lock the object. Rather, if a different
thread asks for the same object lock, it must wait. It is vital that all access to the
object be synchronized. If a second thread does not ask for the lock, it can change
the object's state while the first thread is holding the lock.

Jim ... ...

[Henry Wong]

Jim Hoglund wrote:Good explanation but here is one adjustment. The JVM does not stop other threads.

Agreed. A mutex is a very simple concept (it is also cooperative, as no threads are forced to use it).

Think of it as simple a flag. When a thread tries to acquire it, if it is unowned, the flag is merely set, and the code continues. If it is owned, the thread will merely place itself into a wait state, to wait for the flag to be unset. When the owner of the lock releases the lock, it will trigger a waiting thread to be placed in a runnable state. That's it.

There is no complex JVM thingy that stops threads -- makes things "single threaded". It is just a bunch of threads following simple actions around setting and clearing a flag. Of course, there are tons of details, and race conditions around this, but all you need to understand is the simple concept.

Henry

[Ronald Vermeij]

Thanks for the feedback Henry and Jim.

Do I understand it correctly if I replace

2 - The JVM switches from "Multi-threading" (of all threads running in memory at the same time) turns into "Single threading" (execution only of the SynchronizedCounter. object/thread)

with

2 - The JVM executes only the SynchronizedCounter. object/thread, and put all other threads "on hold" until the SynchronizedCounter. object/thread is ready

Thanks for your feedback and wishing you a nice weekend!

Ronald

[Jim Hoglund]

Ronald : My observation was that the JVM does not switch to a
different mode. Other threads remain running, time-sliced by the JVM.
In fact, your synchronized method can be swapped out, and another
thread can run the same method. This is not a problem as long as the
second thread operates on a different object. Again, threads do not
stop or start based on synchronized code. Methods are not locked;
only objects are locked.

Jim ... ...

[Ronald Vermeij]

Jim Hoglund wrote:Ronald : My observation was that the JVM does not switch to a different mode. Other threads remain running, time-sliced by the JVM. In fact, your synchronized method can be swapped out, and another thread can run the same method. This is not a problem as long as the second thread operates on a different object.

Again, threads do not stop or start based on synchronized code. Methods are not locked; only objects are locked.
Jim ... ...

Thanks for the clarification Jim! I really appreciate your help on this complex matter!

Question
May i ask how and where you learned this indepth Java Multithreading knowlegde?

[Jim Hoglund]

I learned a lot about Java threads while writing a program used for database
performance tuning. It simulated hundreds of simultaneous users, a thread
per user, doing random database transactions. I have also studied tutorials
and books. Always keep an open mind about your understanding of threads.
It is a complex topic and it's easy to come to a flawed understanding that
must be adjusted as we learn more. I still follow many misleading trails.

Jim ... ...

[Thomas Hauck]

The following page describes how
access to shared objects is synchronized among multiple threads.

http://www.j2eeonline.com/java2-programmers-certification/module7/synchronized-shared-objects.jsp

[Thomas Hauck]

The previous link posted on August 16, 2015

http://www.j2eeonline.com/java2-programmers-certification/module7/synchronized-shared-objects.jsp

has changed to


Synchronized Shared Objects