[rfc][icedtea-web] Cache Locking Tests : Potential Deadlock Fix

[Jie Kang]

----- Original Message -----
> On 09/23/2014 05:07 PM, Jie Kang wrote:
> > Hello,
> >
> > Jiri reported deadlock occurring in the unit tests for CacheLRUWrapper.
> > This most likely occurred in the multi-threaded test where the parent
> > thread sleeps for 2 seconds, before attempting to wake the sleeping
> > children. If the children have not completed their tasks within two
> > seconds, they will not be waiting for the parent thread to wake them, and
> > a deadlock can occur. This issue could also occur in CacheEntry, which has
> > a multi-threaded test that functions similarly. This patch resolves the
> > problem. Sorry for the mistake.
> >
> > Regards,
> >
> Uff... Quite hard to understand what is this supposed to do. ANyway - why the
> sleeps here?

Hello,


Good question. After thinking about it some more I have changed them from sleeps to waits on listener objects.

+        //Would like thread a to acquire lock first
+        Thread.sleep(1000l);
+

This sleep is in the hopes that thread A will acquire the lock before we start thread B. Now that I think about it, the test can be changed to allow both threads to go whenever.

The test now doesn't care which thread goes when, and now also runs 100 threads just to increase chance of concurrency issues being seen.


+        //Wait for both children to signal (integer increments from 0, to 2)
+        while (childSignal.get() < 2) {
+            Thread.sleep(1000l);
+        }

These sleeps are to wait for both children to signal. Note that signalling does NOT mean that the thread has ended which is why I cannot use Thread.join. 

However..., now that I think about it this can be replaced with a wait on some new Object() lock. Now parent thread waits on parentListener and child threads wait on childListener. Parent signals children through parentSignal, children signal to parent through childrenSignal. It's a bit confusing though tbh.

I have also added more comments to try to better explain what is going on.

Attached is a revised patch.


Thanks!

> 
> 
> J.
> 

-- 

Jie Kang
-------------- next part --------------
A non-text attachment was scrubbed...
Name: itw-cachelock-deadlock-2.patch
Type: text/x-patch
Size: 14402 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20140924/afcd0909/itw-cachelock-deadlock-2-0001.patch>