Hi Martin, i incorporated the recent changes from the pointer as well. I
have reproduced the failure, the logs of which are attached to the bug
JDK-6772009 <https://bugs.openjdk.java.net/browse/JDK-6772009> . The
failed log is especially interesting .
--
Thanks
kalyan
On 11/18/13 10:15 PM, Martin Buchholz wrote:
Thanks for working on this.
There have been some recent upstream changes to this test as well.
Please incorporate them.
http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/test/jtreg/util/concurrent/locks/ReentrantLock/CancelledLockLoops.java?view=co
The jsr166 maintainers haven't been able to reproduce any failures in
this test. Do you have any hints that might help us?
On Mon, Nov 18, 2013 at 10:12 PM, srikalyan chandrashekar
<srikalyan.chandrashe...@oracle.com
<mailto:srikalyan.chandrashe...@oracle.com>> wrote:
Hi all, I am working on bug JDK-6772009
<https://bugs.openjdk.java.net/browse/JDK-6772009> .
Root Cause:
The timeout value gives too much grace period on faster machines
on which the "TO BE INTERRUPTED" threads complete faster before
being interrupted at right time.
Suggested Fix:
a) Decrease the timeout from 100 to 50ms which will ensure that
the test will pass even on faster machines , and ensures the
threads will be canceled when running and anyways there is a
Barrier to ensure the test threads all complete gracefully.
Miscellaneous fixes
b) Convert result from int to long(possible integer overflow
otherwise)
c) Catch BrokenBarrierException in more granular fashion in
ReentrantLockLoop to update and print the results (which will be
missed otherwise)
Add more diagnostics
d) Assign names to threads
e) Print which threads update the 'completed' variable.
I have attached the webrev for convenience as the changes are
interleaved and is best viewed as sdiff.
Please let me know if you have any comments or suggestions.
Thank you
--
--
Thanks
kalyan
