[concurrency-interest] Design of Thread Safe Iterator Proxy

Nathan Reynolds nathan.reynolds at oracle.com
Mon Jun 24 16:26:35 EDT 2013


The lock needs to be acquired in hasNext() and released when the thread 
calls hasNext() again or remove().  It has to hold the lock until the 
next hasNext() since the thread could call remove().  If the thread 
calls remove() outside of the lock then underlying collection may have 
been changed.

Typically what I do is have hasNext() cache the object.  Then next() and 
remove() use that object in their operations.  next() will succeed 
because of the cached object.  remove() may or may not succeed.  Either 
way, it doesn't throw an exception.

Another idea is to just allow for calling next().  If there are no more 
objects available, then next() returns null or an end of "stream" object.

Nathan Reynolds 
<http://psr.us.oracle.com/wiki/index.php/User:Nathan_Reynolds> | 
Architect | 602.333.9091
Oracle PSR Engineering <http://psr.us.oracle.com/> | Server Technology
On 6/23/2013 12: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.
>
>>
>> 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/20130624/186aa540/attachment.html>


More information about the Concurrency-interest mailing list