-
Bug
-
Resolution: Incomplete
-
P4
-
None
-
8
-
generic
-
generic
-
Not verified
A DESCRIPTION OF THE PROBLEM :
It is possible to wake up a redundant thread.
For example,if you are using ReentrantLock, you are essentially using aqs.One thread prepares to acquire the lock and another thread prepares to release the lock.
Thread 1 and Thread 2
timestamp1:Thread 1 already acquired the lock(reentrantLock.lock()).
timestamp2:Thread 2 tries to acquire lock, create queue.(reentrantLock.lock()).
timestamp3:Thread 2 calls the shouldParkAfterFailedAcquire method with the head node set to SIGNAL (-1).(in loop,so retry)
timestamp4:Thread 1 releases the lock.(reentrantLock.lock())
timestamp5:Thread 1 calls the unparkSuccessor method to wake up thread 2 (LockSupport.unpark(s.thread)).(But thread 2 is not in the waiting stateļ¼so record the state to use in future)
timestamp6:Thread 2 retries to acquire the lock successfully
The problem is that if thread 2 tries to actively call the LockSupport.park() method to be waiting state, it will not enter the waiting state.
It is possible to wake up a redundant thread.
For example,if you are using ReentrantLock, you are essentially using aqs.One thread prepares to acquire the lock and another thread prepares to release the lock.
Thread 1 and Thread 2
timestamp1:Thread 1 already acquired the lock(reentrantLock.lock()).
timestamp2:Thread 2 tries to acquire lock, create queue.(reentrantLock.lock()).
timestamp3:Thread 2 calls the shouldParkAfterFailedAcquire method with the head node set to SIGNAL (-1).(in loop,so retry)
timestamp4:Thread 1 releases the lock.(reentrantLock.lock())
timestamp5:Thread 1 calls the unparkSuccessor method to wake up thread 2 (LockSupport.unpark(s.thread)).(But thread 2 is not in the waiting stateļ¼so record the state to use in future)
timestamp6:Thread 2 retries to acquire the lock successfully
The problem is that if thread 2 tries to actively call the LockSupport.park() method to be waiting state, it will not enter the waiting state.