thread safe to lock on key,val pairs on a dict instead of entiredict?

[birdsong]

Dictionaries just store references to objects, right? So is it thread
safe to lock a specific key/val pair on a dictionary and modify its
val and release the lock?

example snippet:
# assuming d_lock was initialized long ago in a thread-safe manner
d_lock.acquire()
d = {}
d[1] = (threading.Lock(), [])
d_lock.release()

# test key level locking
for key, data in d.items():
row_lock, rows = data
row_lock.acquire()
rows.append(1)
row_lock.release()

Of course, I'll have to lock the entire dict when adding keys that
dont exist, but further calls and acquire the key specific lock before
doing any write operations.

 

[Gabriel Genellina]

Dictionaries just store references to objects, right? So is it thread
safe to lock a specific key/val pair on a dictionary and modify its
val and release the lock?

example snippet:
# assuming d_lock was initialized long ago in a thread-safe manner
d_lock.acquire()
d = {}
d[1] = (threading.Lock(), [])
d_lock.release()

# test key level locking
for key, data in d.items():
row_lock, rows = data
row_lock.acquire()
rows.append(1)
row_lock.release()

Of course, I'll have to lock the entire dict when adding keys that
dont exist, but further calls and acquire the key specific lock before
doing any write operations.

(All of this applies to CPython only)
Subscript assignment is a single opcode. If the key's __hash__ and
__eq__/__cmp__ don't call any Python code, nor does the destructor of the
previous dict entry, then the operation is atomic (no other thread may be
executed due to the GIL).
list.append is atomic.

Note that the *append* operation is atomic (or the dict assignment), not
the whole statement:
L.append(some[values]+to**be.computed(L))
Evaluating the argument to append isn't atomic at all.

References:
http://effbot.org/pyfaq/what-kinds-of-global-value-mutation-are-thread-safe.htm
http://effbot.org/zone/thread-synchronization.htm
http://coreygoldberg.blogspot.com/2008/09/python-thread-synchronization-and.html