-
Bug
-
Resolution: Incomplete
-
P4
-
None
-
8
-
generic
-
generic
A DESCRIPTION OF THE PROBLEM :
In the case that thread-1 already holds the lock, thread-2 tries to acquire the lock, then executes the method "shouldParkAfterFailedAcquire" and gets the result "true". But "parkAndCheckInterrupt" has not been executed yet.
At this situation, Thread-1 finishes executing the method "LockSupport.unpark(s.thread)", and then Thread-2 executes the method "LockSupport.park(this)", which is written in the method "parkAndCheckInterrupt". Since the method "LockSupport.park(this)" is executed, thread-2 is in the "WAITING" state.
Therefore, when other threads try to acquire the lock again, they will be in the "WAITINT" state as well, which will make the program get stuck.
---------- BEGIN SOURCE ----------
if (shouldParkAfterFailedAcquire(p, node) && parkAndCheckInterrupt())
---------- END SOURCE ----------
FREQUENCY : occasionally
In the case that thread-1 already holds the lock, thread-2 tries to acquire the lock, then executes the method "shouldParkAfterFailedAcquire" and gets the result "true". But "parkAndCheckInterrupt" has not been executed yet.
At this situation, Thread-1 finishes executing the method "LockSupport.unpark(s.thread)", and then Thread-2 executes the method "LockSupport.park(this)", which is written in the method "parkAndCheckInterrupt". Since the method "LockSupport.park(this)" is executed, thread-2 is in the "WAITING" state.
Therefore, when other threads try to acquire the lock again, they will be in the "WAITINT" state as well, which will make the program get stuck.
---------- BEGIN SOURCE ----------
if (shouldParkAfterFailedAcquire(p, node) && parkAndCheckInterrupt())
---------- END SOURCE ----------
FREQUENCY : occasionally