[concurrency-interest] Design of Thread Safe Iterator Proxy

Peter Levart peter.levart at gmail.com
Tue Jun 25 08:48:55 EDT 2013


On 06/23/2013 09:20 AM, corporate.piyush at gmail.com wrote:
> sorry for late reply...
>
> @Remi & @Yuvit
>
> thanks for your time.
> I know that concrete solution to this problem is not possible as 
> hasNext() and next() are two different methods.
>
> But we can at least think of Safe Iterator proxy , assuming the following
>
> 1. every thread which calls hasNext() is expected to call next() , 
> again in order
> 2. once a particular thread calls hasNext(), a lock will be active 
> until the same thread calls next() and retrieves the element from 
> underlying iterator
> 3. during the execution of step 2, all other threads have to wait for 
> their turn.
>
>
> Regards,
> Piyush Katariya
>
> -----Original Message----- From: Remi Forax
> Sent: Monday, June 17, 2013 4:34 AM
> To: concurrency-interest at cs.oswego.edu
> Subject: Re: [concurrency-interest] Design of Thread Safe Iterator Proxy
>
> On 06/10/2013 08:37 AM, piyush katariya wrote:
>> Hi,
>>
>>        so i was in the need of ThreadSafe iterator, so that multiple 
>> threads can access over it concurrently without throwing 
>> "ConcurrentModificationException".
>>
>> i came with solution attached herewith, but for some reason..multiple 
>> threads from thread pool after iterating over, stucks...
>>
>> can somebody help me with it..
>>
>
> I can explain why your program deadlock, it's easy.
> I will only explain why it deadlock if the client code is:
>   while(hasNext()) { it.next(); }
> but it can also deadlock is hasNext is called multiple times without
> calling next and vice-versa.
>
> so if the client code is:
>   while(hasNext()) { it.next(); }
> when hasNext returns false, next is not called because you go out of the
> loop but you still hold the lock,
> so the next thread will stop when trying to acquire the lock in hasNext.
>
> BTW, I think there is no way to write a thread-safe proxy iterator if
> remove() is supported.

Bu if you don't need remove() method, then the following might be a 
better approximation. It only requires that the thread that got a true 
result from hasNext() also calls next() at least once after that (Note: 
I would not encourage you to use such Iterator in you code if you can 
solve your problem otherwise, like using BlockingQueue for example...):


public class ConcurrentIterator<T> implements Iterator<T> {
     private final Iterator<T> iterator;

     public ConcurrentIterator(Iterator<T> iterator) {
         this.iterator = iterator;
     }

     // fair lock allows previous waiters to have priority over thread 
that had lock,
     // released it and attempts to gain it immediately after that...
     private final ReentrantLock lock = new ReentrantLock(true);

     @Override
     public boolean hasNext() {
         if (!lock.isHeldByCurrentThread()) {
             lock.lock(); // obtain lock if necessary
         }

         try {
             if (iterator.hasNext()) {
                 return true;
             }
         }
         catch (Throwable t) {
             lock.unlock(); // unlock and re-throw when hasNext() throws
             throw t;
         }

         lock.unlock(); // also unlock immediately when no more elements
         return false;
     }

     @Override
     public T next() {
         if (!lock.isHeldByCurrentThread()) {
             lock.lock(); // obtain lock if necessary
         }

         try {
             return iterator.next();
         }
         finally {
             lock.unlock(); // unlock immediately regardless of outcome
         }
     }

     @Override
     public void remove() {
         throw new UnsupportedOperationException();
     }
}


Regards, Peter

>
>>
>> Regards,
>> Piyush Katariya
>
> cheers,
> Rémi
>
>
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20130625/5b1abeca/attachment.html>


More information about the Concurrency-interest mailing list