(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 

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 

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 


More information about the hotspot-runtime-dev mailing list