[concurrency-interest] ConcurrentSkipList issues:

Yechiel Feffer yechielf at gigaspaces.com
Mon Apr 25 08:31:36 EDT 2005

I am considering the usage of ConcurrentSkipList (here CSL) - it will be
(once mustang is released) the only "ordered" concurrent set.
I have some questions/wishes regarding it
#1) Iterators: they are weakly consistent, which is fine. But the point I
want to clarify is: When I create an iterator, am I guaranteed to get all
the elements which were part of the iteration set when the iterator was
created and are still valid (- not deleted) when I exhaust the iteration set
? i.e. I want to make sure that an element will not disappear from the
iteration set as a result of deletions/additions of other elements to the
#2) null values- why cant they be used ? I know that null is used inside the
CSL as a logical indication of a deleted node but this can be changed by
using a boolean as a deleted-indicator or, (if boolean is not relevant for
CSL cas operations) a null value can be substituted inside the CSL by a
null-representative special object which will participate in the comparisons
using the null terminology defined (nulls-first or nulls-last will do)
#3) wishful performance optimization- is it possible to create an additional
set of apis to the CSL which will return a "handle" from the put api . The
handle will be a direct "pointer" to the CSL so when I want to remove a key
from the CSL (assuming I keep the handles) I can render this handle and
spare the need for a redundant search . Same is true for replace. 

Doug- your input will be highly appreciated

Yechiel Fefer        
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20050425/6ec73fac/attachment.htm

More information about the Concurrency-interest mailing list