I have read different things in different blogs about monitors. So I'm a bit confused now.
As much as I understand, monitor is a somebody who would make sure that only one thread is executing the code in the critical section. So is it like if we have 3 synchronized methods/blocks then we would have 3 monitors to make sure that only one thread is in the critical section?
If the above is true then why it is said that in Java every object has a monitor associated with it? It should be every synchronized block is associated with a monitor.
What is a monitor?
A monitor is something a thread can grab and hold, preventing all other threads from grabbing that same monitor and forcing them to wait until the monitor is released. This is what a synchronized block does.
Where do these monitors come from in the first place?
The answer is: from any Java object. When you write:
Object foo = new Object();
synchronized (foo) {
System.out.println("Hello world.");
}
...what this means is: the current thread will first grab the monitor associated with the object stored in variable foo and hold it while it prints "Hello world", then releases it.
Why does every Java object have a monitor associated with it?
There is no technical reason for it to be that way. It was a design decision made in the early versions of Java and it's too late to change now (even though it is confusing at first and it does cause problems if people aren't careful).
When using synchronized with blocks, you specify an object to lock on. In that case, the monitor of that object is used for locking.
When using synchronized with methods, you don't specify an object to lock on, and instead this object is implied. Again, the monitor of this is used for locking.
So, objects have monitors, and synchronized methods/blocks do not have their own monitors, but instead they use the monitors of specific objects.
In the context of Java programming, the monitor is the intrinsic lock (where intrinsic means "built-in") on a Java object. For a thread to enter any synchronized instance method on an object it must first acquire the intrinsic lock on that object. For a thread to enter any synchronized static method on a class it must first acquire the intrinsic lock on that class.
This is how monitor is defined in the Java tutorial:
Synchronization is built around an internal entity known as the intrinsic lock or monitor lock. (The API specification often refers to this entity simply as a "monitor.")
There is a good reason that the monitor belongs to an object, and not to an individual block: the monitor is there to protect the state of the object. Objects should be designed to be cohesive, making it likely that instance variables will end up being referenced by multiple methods; the safe thing to do, in order to guarantee that the object is always in a consistent state, is to allow only one synchronized method on that object to execute at a time.
The term "monitor" comes from Concurrent Pascal. See Per Brinch Hansen's paper "Java's Insecure Parallelism", which argues that Java doesn't actually implement monitors:
Gosling (1996, p. 399) claims that Java uses monitors to synchronize threads. Unfortunately, a closer inspection reveals that Java does not support a monitor concept:
Unless they are declared as synchronized, Java class methods are unsynchronized.
Unless they are declared as private, Java class variables are public (within a package)
Another quote from the same paper:
The failure to give an adequate meaning to thread interaction is a very deep flaw of Java that vitiates the conceptual integrity of the monitor concept.
Related
In order to properly understand the issues and solutions for concurrency in Java, I was going through the official Java tutorial. In one of the pages they defined Intrinsic Locks and Synchronization link. In this page, they say that:
As long as a thread owns an intrinsic lock, no other thread can
acquire the same lock. The other thread will block when it attempts to
acquire the lock.
Also, they mention in the section Locks In Synchronized Methods that:
When a thread invokes a synchronized method, it automatically acquires
the intrinsic lock for that method's object and releases it when the
method returns. The lock release occurs even if the return was caused
by an uncaught exception.
For me this means that once I call a synchronized method from one of the threads, I will have hold of the intrinsic lock of the thread and since
Intrinsic locks play a role in both aspects of synchronization:
enforcing exclusive access to an object's state and establishing
happens-before relationships that are essential to visibility.
would another thread be unable to call another synchronized method of the same class? If yes, then the whole purpose of having synchronized methods is defeated. Isn't it?
Seems you have one misunderstanding (dunno if it caused the wrong conclusion) that no one has pointed out. Anyway, a brief answer:
Intrinsic Lock: Just think it as, every object in JVM has internally a lock. synchronized keywords tries to acquire the lock of the target object. Whenever you synchronized (a) { doSomething; }, what actually happens is
the lock in a is acquired
code within the synchronized block is run (doSomething)
release the lock in a
and I wish you know
public synchronized void foo() {
doSomething;
}
is conceptually the same as
public void foo() {
synchronized(this) {
doSomething;
}
}
Ok, go back to your question, the biggest problem, imho, is :
For me this means that once I call a synchronized method from one of the threads, I will have hold of the intrinsic lock of the thread and since...
It is wrong. When you call a synchronized method, you are not get hold of the lock of the thread.
Instead, that thread will own the intrinsic lock of the object that is "owning" the method.
e.g. in thread1, you called a.foo(), and assume foo() is synchronized. thread1 is going to acquire the intrinsic lock of the object a referring.
Similarly, if AClass.bar() is called (and bar is synchronized and a static method), the intrinsic lock of AClass Class object will be acquired.
So just to repeat my comment above as an answer. Intrinsic locking means that you don't have to create an object to synchronize your methods on. In comparison you can use an extrinsic lock by calling synchronized(myLock) {...}.
This is an excerpt from the book Java Concurrency in Practice: "The fact that every object has a built-in lock is just a convenience so that you needn't explicitly create lock objects"
The book also says:
There is no inherent relationship between an object's intrinsic lock
and its state; an object's fields need not be guarded by its intrinsic
lock, though this is a perfectly valid locking convention that is used
by many classes. Acquiring the lock associated with an object does not
prevent other threads from accessing that objectthe only thing that
acquiring a lock prevents any other thread from doing is acquiring
that same lock. The fact that every object has a built-in lock is just
a convenience so that you needn't explicitly create lock objects. [9]
It is up to you to construct locking protocols or synchronization
policies that let you access shared state safely, and to use them
consistently throughout your program.
But in the footnote it says:
[9] In retrospect, this design decision was probably a bad one: not
only can it be confusing, but it forces JVM implementors to make
tradeoffs between object size and locking performance.
And to answer your last questions: you won't be able to call the synchronized methods from another thread, but you can keep entering from the same thread (intrinsic locks are re-entrant). So you have to imagine locking in this case as serializing method access from different caller threads.
If you use locking improperly and then you introduce liveness hazards, then yes it is defeated. That's why you have to make sure that your concurrent threads are not contending with each other too hard.
As Brian Goetz puts in this blog entry:
In tuning an application's use of synchronization, then, we should try
hard to reduce the amount of actual contention, rather than simply try
to avoid using synchronization at all
A lock can be held by only one thread at a time. That doesn't defeat the purpose; that is the purpose.
Threads mutually exclude each other from simultaneous action in critical sections by acquiring a lock, or mutex. This provides effective atomicity around a series of distinct actions, so that other threads never see intermediate states that might violate consistency guarantees.
Yes, you won't be able to call other synchronized method on the same object, because of the intrinsic lock. Which is at object level, only 1 thread will acquire it.
would I be unable to call another synchronized method of the same class? If yes, then the whole purpose of having synchronized methods is defeated. Isn't it?
No. You can't call other synchronized method on same object for Object level lock and you can't call other static sysnchronized method on same class.
But it does not defeat the purpose of having synchronisation.
If you follow the other documentation page on synchronized methods:
Making these methods synchronized has two effects:
First, it is not possible for two invocations of synchronized methods on the same object to interleave. When one thread is executing a synchronized method for an object, all other threads that invoke synchronized methods for the same object block (suspend execution) until the first thread is done with the object.
Second, when a synchronized method exits, it automatically establishes a happens-before relationship with any subsequent invocation of a synchronized method for the same object. This guarantees that changes to the state of the object are visible to all threads.
If you allow two synchronized method to run in parallel. you will bound to get memory inconsistency errors on shared data.
On a different note, Lock provides better alternative synchronized construct.
Related SE question:
Synchronization vs Lock
It doesn't matter whether the synchronized method belongs to the same class or not, what matters is if the caller thread of the method acquires the lock or not, if it does, then it will be allowed enter the critical section because the lock is reentrant.
If it wasn't the case, then a recursive call would cause a deadlock,
fn(){
synchronized(mutex){ // the current thread has already acquired the mutex
fn();
}
}
fn here wont deadlock because the lock is re-entrant, ie ( the thread that's already acquiring the lock can enter and renter the critical section again as long as it is still acquired).
Locks can be divided in two classes - 'reentrant' and 'not reentrant'.
In Java 'synchronized', base implementation of interface Lock (class ReentrantLock), interface ReadWriteLock (class ReentrantReadWriteLock) - are reentrant.
Reentrancy means - one thread can again and again hold the lock.
When to prefer private lock object to synchronize a block over intrinsic lock(this)?
Please cite the upshots of both.
private lock object:-
Object lock =new Object();
synchronized(lock)
{ }
intrinsic lock(this):-
synchronized(this)
{ }
Using explicit lock objects can allow different methods to synchronize on different locks and avoid unnecessary contention. It also makes the lock more explicit, and can make it easier to search the code for blocks that use the lock.
You probably don't want to do either, however! Find the appropriate class in java.util.concurrent and use that instead. :)
A private lock can be useful if you are doing some kind of lock sharding, i.e., you need to only lock certain parts of your object while others can still be accessed by a different client.
One simple parallel to understand this concept is a table lock in a database: if you are modifying one table, you acquire the lock on that single table, not the whole database, so the rest of the tables can be modified by other clients. If you need to implement a similar logic but in a POJO you would use as many private locks as necessary.
One downside of this approach is that your class gets cluttered with a lot of objects. This might be indication that you need to refactor it in a more granular set of classes with a simpler locking strategy but it all depends on your design and implementation.
These are both using intrinsic locks. Your first example is using the intrinsic lock of lock, while the second is using the intrinsic lock of this. The question is whether or not this is really what you want to lock on, which it often isn't.
Consider the case, when you use synchronized(this) inside one of your methods. You have 2 objects of this class, and these objects reference some shared resource. If you lock on this then you will not have mutual exclusivity to that resource. You need to lock on some object that everything that can access the resource has access to.
Lock on this ONLY if the important resource is part of the class itself. Even then in some cases a lock object is better. Also, if there's several different resources in your class, that do not need to be mutually exclusive as a whole, but individually, then you need several lock objects.
The key is to really just know how synchronized works, and be mindful of what your code is actually doing
Actually, using either won't make any difference, it is more about choice/style, API writers will lock on the Object -either by synchronized(this) or explicit synchronized on any Object method-, or use an internal monitor depends on sharing a resource, you might not want API users to access your internal lock or you might want to give the choice to API users to share the Object intrinsic lock.
Either way none of those choices are wrong, it is more about the intention of such lock.
Read Java Concurrency in Practice, that will make you a master of concurrency and clarify many of those concepts, which sometimes are more related with the choice you make rather than correctness.
Each object has only one intrinsic lock.
With the synchronized keyword: if you call two synchronized methods from the same object from two different threads, even-thought one thread could run method one and the other thread could run method two, that will not happen because both methods share the same intrinsic lock (which belongs to the object). And according to that one thread will have to wait for the other thread to finish before it can acquire the intrinsic lock to run the other method.
But if you use multiple locks, you will make sure that only one thread can access method one at a time and that only one thread can access method two at a time. But you will allow that method one and method two can be accessed by one thread each at the same time and then reducing the time required for the operation.
rephrased for clarity
I would like to be able to mix the use of the synchronized block with more explicit locking via calling lock and release methods directly when appropriate. Thus allowing me the syntaxtical sugar of using sychtronized(myObject) when I can get away with it, but also being able to call myObject.lock & myObject.unlock dierctly for those times when a synchronized block is not flexible enough to do what I need done.
I know that every single Object has, implicitly, a rentrant lock built into it which is used by the synchronized block. Effectively the the lock mthod is caled on the Objects internal reentrant lock every time one enters a sychronized block, and unlock is called on the same reentrant lock when you leave the synchronized block. I would seem as if it wouldn be easy enough to allow one the ability to manually lock/unlock this inplicit reentrant lock; thus allowing a mixing of synchronized blocks and explcit locking.
However, as far as I know there is no way to do this. And because of the way synchronized blocks work I don't believe there is a convenient way to mix them with explicit locking othewrise. It seems as if this would be a rather convenient, and easily added by expending the Object api to add lock/unlock methods.
The question I have is, why doesn't this exist? I'm certain there is a reason, but I don't know what it is. I thought the issue may be with encapsulation; same reason you don't want to do synchronize(this). However, if I am already calling sycnhronized(myObject) then by defination anyone who knows about myObject can likewise synchronize on it and cause a deadlock if done foolishly. The question of encapsulation comes down to who can access the object you synchronized on regardless of rather you use a sychtronized block or manually locked the object; at least as I see it. So is there some other advantage to not allowing one to manually lock an object?
The locks of a certain object is highly tied to the instance itself. The structure of the synchronized blocks and methods are very strict. If you, as a programmer, would have the possibility to interfere with the system (virtual machine), it could cause serious problems.
You could eventually release a lock that was created by a synchronized block
You create a lock that another synchronized block will release
You create more lock entries than exits
You create more lock exits than entries
There are even specific bytecodes defined for the lock and release operations. If you would have a "method" for this lock/unlock operation, it should be compiled to these bytecodes. So, it is really a low-level operation, and very much different from other Java object level implementations.
Synchronisation is a very strong contract. I think that the designers of the JLS did not want to allow the possibility to break this contract.
The Chapter 17 of the JLS describes more about the expected behaviour.
When reading articles about Java threads, I often notice the expression: "current thread is the owner of this object's monitor". I get the meaning: the thread gets the right to operate on the object. But I am puzzled why we use the phrase "the object's monitor" instead of "the object's lock"?
In brief, I don't know the meaning of the word 'monitor'
The question may be strange and simple. But I wish anybody can help to solve it. 3ks
but I am puzzled why use word "the object's monitor" instend of "the object's lock"?
See ulmangt's answer for links that explain the term "monitor" as used in this context. Note that:
"Monitors were invented by Per Brinch Hansen and C. A. R. Hoare, and were first implemented in Brinch Hansen's Concurrent Pascal language."
(Source: Wikipedia)
Why use the term "monitor" rather than "lock"? Well strictly speaking, the terms do mean different things ... especially if you use them in the way that they were originally intended to be used.
A "lock" is something with acquire and release primitives that maintain certain lock properties; e.g. exclusive use or single writer / multiple reader.
A "monitor" is a mechanism that ensures that only one thread can be executing a given section (or sections) of code at any given time. This can be implemented using a lock (and "condition variables" that allow threads to wait for or send notifications to other threads that the condition is fulfilled), but it is more than just a lock. Indeed, in the Java case, the actual lock used by a monitor is not directly accessible. (You just can't say "Object.lock()" to prevent other threads from acquiring it ... like you can with a Java Lock instance.)
In short, if one were to be pedantic "monitor" is actually a better term than "lock" for characterizing what Java is providing. But in practice, both terms are used almost interchangeably.
A monitor is simply a term for an object whose methods can be safely used in a multithreaded environment.
There's a great Wikipedia article on Monitors:
http://en.wikipedia.org/wiki/Monitor_(synchronization)
If you scroll down, it's even got a section explicitly about Java.
Quote from Inside the Java Virtual Machine
A thread in the Java virtual machine requests a lock when it arrives
at the beginning of a monitor region. In Java, there are two kinds of
monitor regions: synchronized statements and synchronized methods.
Monitor
A monitor is like a building that contains one special room that can
be occupied by only one thread at a time. The room usually contains
some data. From the time a thread enters this room to the time it
leaves, it has exclusive access to any data in the room. Entering the
monitor building is called "entering the monitor." Entering the
special room inside the building is called "acquiring the monitor."
Occupying the room is called "owning the monitor," and leaving the
room is called "releasing the monitor." Leaving the entire building is
called "exiting the monitor."
In addition to being associated with a bit of data, a monitor is
associated with one or more bits of code, which in this book will be
called monitor regions.
As mentioned earlier, the language provides two built-in ways to
identify monitor regions in your programs: synchronized statements and
synchronized methods. These two mechanisms, which implement the mutual
exclusion aspect of synchronization, are supported by the Java virtual
machine's instruction set.
Lock
To implement the mutual exclusion capability of monitors, the Java
virtual machine associates a lock (sometimes called a mutex) with each
object and class. A lock is like a privilege that only one thread can
"own" at any one time.
A single thread is allowed to lock the same object multiple times. For
each object, the Java virtual machine maintains a count of the number
of times the object has been locked. An unlocked object has a count of
zero. When a thread acquires the lock for the first time, the count is
again incremented to one. Each time the thread acquires a lock on the
same object, the count is again incremented.
A synchronized block around an object is its monitor, which controls a lock on the object. Here an example
synchronized (object) {
while (<condition does not hold>)
object.wait(timeout);
... // Perform action appropriate to condition
}
The Java Virtual Machine uses monitors to support multithreading. Monitors achieve this through two concepts - Mutual exclusion while running the threads (here is where 'locking' comes into picture) and coordination as a means of inter thread communication (here is where object's wait and notify methods come into picture).
Reading the following part from "Inside JVM" will clear this doubt, is it very nicely explained over here (Chapter 20, Thread synchronization) -
https://www.artima.com/insidejvm/ed2/threadsynchP.html
Even though it is late to answer this question, I thought to just add in-case it is useful.
Here is a synchronized block of Java code inside an unsynchronized Java method
public void add(int value){
synchronized(this){
this.count += value;
}
}
In the example "this" is used, which is the instance the add method is called on.
A synchronized instance method uses the object it belongs to as monitor object.
=> Only one thread can execute inside a Java code block synchronized on the same monitor object.
I am learning java multi-threading, I found it's hard to understand how synchronized block works:
synchronized(Object o){
// do something
}
please give some example code that can show me the Object o is blocked. As how I understand this, accessing object o from another thread will be blocked while the synchronized block is being excuted?
Synchronization in Java is an important concept since Java is a multi-threaded language where multiple threads run in parallel to complete program execution. In multi-threaded environment synchronization of java object or synchronization of java class becomes extremely important. Synchronization in Java is possible by using java keyword "synchronized" and "volatile”. Concurrent access of shared objects in Java introduces to kind of errors: thread interference and memory consistency errors and to avoid these errors you need to properly synchronize your java object to allow mutual exclusive access of critical section to two threads.
Read more: http://javarevisited.blogspot.com/2011/04/synchronization-in-java-synchronized.html#ixzz2LOWwnCjH
Please Look at this Example
Synchronization describes that if an object or a block is declared as synchronized then only one process can access that object or block at a time.No other process can take the object or block until it is available .Internally each object has one flag named "lock" has two state set and reset. when a process requests one object then it is checked whether the lock value is set or reset. Depending on that one object is available to a process in synchronization . For better understanding with example you can see this link.
enter link description here
As Most of the answers have covered what synchronized means i want to add one extra point which isn't mentioned.
Synchronizing a method or enclosing a block with synchronized ensures that the operation/set of operations execute as a single atomic operation,to be precise when one thread is executing synchronize block on an object no other thread can enter the block until the thread one completes its execution and releases the lock it holds which it gets while entering the block.
So synchronize block ensure atomicity of bunch of code statements.
unlike what #lucifier specified ,Synchronizing and volatile doesn't serve the same purpose ,volatile is meant to ensure that two threads communicate with each other and get the most update value from the main memory instead of accesing a value from individual cache.it also ensures "happens before " behavior for a execution.
For example defining a variable as volatile(volatile int i=10;) an performing a increment operation (i++;)in an unsynchronized method doesnt give the same behavior when (i++) is enclosed in a synchronized block.