[Python-Dev] Repeatability of looping over dicts

[Jeffrey Yasskin]

On Jan 4, 2008 12:05 PM, Tim Delaney <timothy.c.delaney at gmail.com> wrote:
> history of insertions and deletions. If items(), keys(), values(),
> iteritems(), iterkeys(), and itervalues() are called with no intervening
> modifications to the dictionary, the lists will directly correspond.

I looked over the Java code briefly
(http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/ConcurrentHashMap.java:HashIterator)
and I don't see anything that would cause it to violate this
condition. In particular, the locks don't affect the order.  It's a
complicated class though, so I could have missed it. Do you see a
reason for it to change its iteration order spontaneously? If another
thread is concurrently modifying the dict, that's an intervening
modification, and changing the iteration order is fine.

There's the second question of whether using ConcurrentHashMap for
python dicts is a good idea. I can't find any mention of thread-safety
in the Jython docs, so I assume it follows Java's rules, which are
that most variables must be locked in order to be accessed and
modified concurrently. Making dict a ConcurrentHashMap would provide a
stronger guarantee for some built-in types but not others, which is
likely to confuse people. Further, not all synchronized maps can be
replaced by ConcurrentHashMap because you may need groups of
operations to be atomic, while CHM only provides atomicity across
single method calls. I think a new ConcurrentDict class would probably
be a better way to integrate ConcurrentHashMap.

-- 
Namasté,
Jeffrey Yasskin