CODEWITHSUNDEEP
javamultithreadingsynchronizationthread-safety
Justin
Justin

Reputation: 4539

How does a second thread check and recheck the lock object of a class that is current used by the first thread?

My understanding of the synchronized method in java, where the first thread acquires the lock object, so that if the second thread checks it sees it is in use and "waits" until thread one completes, then the lock is passed back, whereas the second thread could acquire the lock and continue. Just learning so if that off/over simplified...that is why.

My question is what are the internal mechanics of the second thread "waiting"...does it continue poll or recheck that lock until it simply sees its free? If that was the case does this impact a bunch of threads running instead of this first/second example? Or is it more of a registration-type of mechanism that allows the second thread to be placed into a queue of sorts and then be notified once the lock is available?

Just curious. Thanks!

Upvotes: 1

Views: 118

Answers (2)

user2982130
user2982130

Reputation:

The way that the JVM handles intrinsic locking varies place to place, factors such as JVM vendor, server/client option, active threads, waiting time, queue size, etc... Are factored into thread behavior on lock.

The implementation of the HotSpot JDK VM in particular will be quite cryptic to the common layman such as myself, I will leave this here for further investigation: http://hg.openjdk.java.net/jdk8u/jdk8u60/hotspot/file/37240c1019fd/src/share/vm/runtime/synchronizer.cpp

Without diving into the source code, AFAIK intrinsic locking keeps a collection of waiting threads that do not own the lock. If a thread attempts to acquire and fails, it is added to this collection and can possibly perform a few different actions:

  1. Spin, many algorithms are possible here. The second thread is notified when the spin succeeds in acquiring the lock.
  2. Context switch, pause the thread and release the processor. Exiting thread notifies the next waiter.
  3. Sleep, pause the thread but retain the processor. Same as 2.

What the thread will do will usually be determined by heuristics or whatever type of lock the thread is acquiring. The system can also combine together different methods such as spinning N number of times before sleeping, then doing a context switch. This is system dependent. I may be wrong about a few or all the points that I have made as I cannot find any references that support what I've said.

Honestly the internal implementation of locking should matter very little to the Java developer. The JVM's thread scheduling and locking is very efficient and the engineers who work on these algorithms are extremely smart and spend weeks, months, and years testing and ensuring that the implementation offers the best performance. This is why the lowest level thread control comes from thread parking, anything lower you will need the JNI or a different language. If you are implementing your own synchronizers, consider AbstractQueuedSynchronizer instead. The JDK source is meticulously well documented and you will see how non-intrinsic locks and other high level synchronizers such as ReentrantLock work.

EDIT

The JVM implementation path goes like so:

  1. runtime/synchronizer.cpp
  2. High level spin
  3. Call to park event
  4. OS call:
  5. Linux only: NPTL -> Futex syscall

Upvotes: 1

Gray
Gray

Reputation: 116908

My question is what are the internal mechanics of the second thread "waiting"...does it continue poll or recheck that lock until it simply sees its free?

This is in most cases handled not by the JVM at all but rather by the thread layer in the OS. That said, the threads are certainly not polling. When the 2nd thread hits a lock that is already locked, it stops running and is put into an ordered wait queue associated with that lock. When the lock is unlocked then the first thread in the wait queue (if any) is awoken and moved into the run queue.

If that was the case does this impact a bunch of threads running instead of this first/second example?

No. The queues scale well up to a large number of threads.

Or is it more of a registration-type of mechanism that allows the second thread to be placed into a queue of sorts and then be notified once the lock is available?

Right. The thread stops running entirely and the thread that unlocks the lock is the one (or some sort of supervisor thread) that starts the thread running again.

Upvotes: 1

Related Questions