3

When we declare a method synchronized then how it is known by second thread that the synchronized section of code used by the first thread is completed and how second thread can use that synchronized section of code?

Nathan Hughes
  • 94,330
  • 19
  • 181
  • 276
PENNY
  • 91
  • 5

5 Answers5

3

The thread scheduler tells the second thread. When a thread exits a synchronized block stuff happens in this order:

  • The exiting thread releases its lock.

  • The lock tells the thread scheduler that it was released.

  • The thread scheduler changes the state of the threads waiting on that lock to "running".

  • The running threads race to acquire the lock, one of them wins, the rest go back to waiting.

The scheduler decides which threads to run and what order to run them in and when to context-switch, so it influences which thread gets the lock, but it doesn't directly hand the lock over to the next thread in line. (Who knows, maybe some implementation does, but you can't count on that behavior in general.)

Nathan Hughes
  • 94,330
  • 19
  • 181
  • 276
  • Just curious, why would threads be racing for the lock? When a thread tries to acquire a lock that is already held it is blocked. When that lock is released, the thread that has been waiting the longest for the lock should be given the lock unless some sort of priority scheduling is happening. But I don't see a difference in the priority of two threads in Java. – Hunter McMillen Nov 18 '11 at 18:41
  • 1
    @Hunter: yes, from reading the spec there is no explicit requirement that they race. but it does say there is no guarantee which thread gets picked either, so your assumption may not hold. it seems to me a race may not happen, but it is within the jvm's rights if there is one and the safest plan is to assume there is one. and yes, priorities in java seem useless. – Nathan Hughes Nov 18 '11 at 18:55
1

Java uses an internal construct called a monitor to manage synchronization, basically when thread 1 enters a synchronized method, it takes control of the monitor, similarly when it is finished it releases the monitor. Any threads that arrive while the monitor is currently held are blocked until the monitor is released. Then they enter the synchronized method.

here is more information on monitors: http://en.wikipedia.org/wiki/Monitor_(synchronization)

Hunter McMillen
  • 59,865
  • 24
  • 119
  • 170
  • +1 Just one note: Lock is also released when wait() is called inside a synchronized block. But only the most inner lock. – Fabian Barney Nov 17 '11 at 18:04
  • @Fatal The locks are inside of the monitor I believe, so when the monitor is released, the monitor internally releases the lock – Hunter McMillen Nov 17 '11 at 22:39
0

Have a look at oracle documentation page to understand concepts clearly.

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.") 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.

Every object has an intrinsic lock associated with it. By convention, a thread that needs exclusive and consistent access to an object's fields has to acquire the object's intrinsic lock before accessing them, and then release the intrinsic lock when it's done with them.

A thread is said to own the intrinsic lock between the time it has acquired the lock and released the lock. 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.

Javaword article by Bill Venners clearnly explains what actually happening under the hoods.

Two opcodes, monitorenter and monitorexit, are used for synchronization blocks

When monitorenter is encountered by the Java virtual machine, it acquires the lock for the object referred to by objectref on the stack. If the thread already owns the lock for that object, a count is incremented.

Each time monitorexit is executed for the thread on the object, the count is decremented. When the count reaches zero, the monitor is released.

Once the monitor is released, one of the waiting threads will acquire the monitor and above process will be repeated again.

Have a look at related SE questions:

What does 'synchronized' mean?

How Synchronization works in Java?

Community
  • 1
  • 1
Ravindra babu
  • 37,698
  • 11
  • 250
  • 211
0

When thread A enters synchronized method, It acquires a LOCK on the Object calling the method, so any other Thread cannot call the synchronized method using that particular object. However any Thread B can call that synchronized method using some other object of the same class.

So once Object is Locked, No thread can call synchronized method using that object until The previous thread release the Lock. and previous thread will release the lock when it has finished executing the synchronized method.

In the mean time if Thread B and Thread C have invoked the same synchrinized method using the same previous object, then they will start waiting for Thread A to release Lock on Object. When Thread A will release Lock on the Object, then Thread B OR Thread C can start executing, There is no guarantee which one will go first. The other one will continue waiting.

Zohaib
  • 7,026
  • 3
  • 26
  • 35
  • It is important to notice that it does not depend on invoking the same synchronized method rather then locking on the same object. – Fabian Barney Nov 17 '11 at 18:24
0

When it is a non-static method then this is equivalent synchronizing over this:

public synchronized void xyz() { ... }

is equivalent to

public void xyz() {
    synchronized(this) {
        ...
    }
}

When it is a static method then it is synchronized over class object instead.

Fabian Barney
  • 14,219
  • 5
  • 40
  • 60