[infinispan-dev] race condition in AsyncStore

Galder Zamarreno galder at redhat.com
Thu Oct 29 09:13:43 EDT 2009


On 10/28/2009 06:16 PM, Manik Surtani wrote:
>
> On 28 Oct 2009, at 17:12, Mircea Markus wrote:
>

</snip>

>
>> I think the way to go is:
>>
>>
>>        void run0() throws InterruptedException {
>>           if (trace) log.trace("Checking for modifications");
>>           boolean unlock = false;
>>           try {
>>              acquireLock(write);
>>              unlock = true;
>>              swap = state;
>> //for each key in the swap acquire a WL. Do this with 0 ms acquisition
>> timeout to make sure that the put does not block.
>
> That would mean a lot of locks.  :)  But yeah that approach would
> work.  Perhaps look at AbstractPerEntryLockContainer to look at how
> such locks are created lazily and destroyed when no longer in use.

Yeah, look per key seems to be the best way forward.

>
>>              state = newStateMap();
>>
>>
>>           } finally {
>>              if (unlock) write.unlock();
>>           }
>>
>>           int size = swap.size();
>>           if (size == 0)
>>              awaitNotEmpty();
>>           else
>>              decrementAndGet(size);
>>
>>           if (trace) log.trace("Calling put(List) with {0}
>> modifications", size);
>>           put(swap);
>>
>> //for each key in the swap release WL
>>        }
>>
>> This way we would make sure that the access *per key* is serialized.
>>
>>
>>>
>>>
>>> On 28 Oct 2009, at 16:51, Mircea Markus wrote:
>>>
>>>> Hi Galder,
>>>>
>>>> This is following an email sent this morning on an infinit loop in
>>>> AsyncTest. I've found what was[1] causing the infinite loop. Here it
>>>> is (see comments in the code):
>>>>
>>>> Let's say we do put(k1, v1) and put(k1, v2) in this order
>>>>
>>>>
>>>>      void run0() throws InterruptedException {
>>>>         if (trace) log.trace("Checking for modifications");
>>>>         boolean unlock = false;
>>>>         try {
>>>>            acquireLock(write);
>>>>            unlock = true;
>>>>            swap = state;
>>>>            state = newStateMap();
>>>>         } finally {
>>>>            if (unlock) write.unlock();
>>>>         }
>>>> //thread ONE comes here and is processing (k1, v1); it releases the
>>>> write lock. Immediately, thread TWO acquires write lock, and takes
>>>> (k1,v2) from the store into its swap.
>>>> // the race condition happens when thread TWO executes (i.e.
>>>> persists)
>>>> before thread one, and as a result in the store the final value
>>>> persisted is v1 (not v2).
>>>> // This is known to be an async (i.e. best effort store), so this
>>>> situation might be considered as normal behavior. Still, I think
>>>> this
>>>> induces unwanted errors/behavior.
>>>> // A possible solution is to only release the WL after put(swap).
>>>>
>>>>
>>>>         if (trace) log.trace("About to insert the swap: " + swap);
>>>>         int size = swap.size();
>>>>         if (size == 0)
>>>>            awaitNotEmpty();
>>>>         else
>>>>            decrementAndGet(size);
>>>>
>>>>         if (trace) log.trace("Calling put(List) with {0}
>>>> modifications", size);
>>>>         put(swap);
>>>>      }
>>>>
>>>> Cheers,
>>>> Mircea
>>>>
>>>>
>>>>
>>>> [1] I say 'was' because I modified the test to fail (intermittently)
>>>> rather than hang
>>>> _______________________________________________
>>>> infinispan-dev mailing list
>>>> infinispan-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>
>>> --
>>> Manik Surtani
>>> manik at jboss.org
>>> Lead, Infinispan
>>> Lead, JBoss Cache
>>> http://www.infinispan.org
>>> http://www.jbosscache.org
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> --
> Manik Surtani
> manik at jboss.org
> Lead, Infinispan
> Lead, JBoss Cache
> http://www.infinispan.org
> http://www.jbosscache.org
>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

-- 
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache



More information about the infinispan-dev mailing list