(S) RFR: 8029453: java/util/concurrent/locks/ReentrantLock/TimeoutLockLoops.java failed by timeout
David Holmes
david.holmes at oracle.com
Tue Aug 11 06:40:38 UTC 2015
Bug: https://bugs.openjdk.java.net/browse/JDK-8029453
Webrev: http://cr.openjdk.java.net/~dholmes/8029453/webrev/
The code introduced in 6900441 contained a bug in the code path for when
WorkAroundNPTLTimedWaitHang was zero, and this was exposed by the change
in 8130728 which made the default setting of WorkAroundNPTLTimedWaitHang
zero.
In PlatformParker on Linux _cur_index tracks which pthread_cond object
is currently in use by a waiting thread (one for relative-timed waits,
the other for absolute-timed waits) and is set to -1 when the thread is
not waiting. In the path now used by default we release the
pthread_mutex_t and then pthread_cond_signal the condition variable at
_cond[_cur_index]. But as soon as we release the mutex the waiting
thread can resume execution (it may have timed-out and so not need the
signal) and set _cur_index to -1. The signalling thread then signals
_cond[-1] which does not contain a pthread_cond_t object. This can
result in the pthread_cond_signal hanging, and potentially other
consequences.
The fix is simple: save the correct index before unlocking the mutex.
The test: java/util/concurrent/locks/ReentrantLock/TimeoutLockLoops.java
has been marked as failing intermittently (8133231) due to this and I
will revert that as part of this fix, once that change reaches the hs-rt
forest.
Thanks,
David
More information about the hotspot-runtime-dev
mailing list