[Python-Dev] Threading idea -- exposing a global thread lock
Raymond Hettinger
raymond.hettinger at verizon.net
Tue Mar 14 23:10:17 CET 2006
[Raymond]
>> While this is a somewhat rough approach, it is dramatically
>> simpler than the alternatives (i.e. wrapping locks around every access to a
>> resource or feeding all resource requests to a separate thread via a Queue).
[Alexander]
> Why is that actually more difficult to write? Consider
>
> res_lock = Lock()
> res = ...
> with locked(res_lock):
> do_something(res)
>
> It is only about supplying the correct lock at the right time.
In the case on the newsgroup, the resource was a mapping or somesuch. Getitem
and setitem accesses were spread throughout the program and it would have been a
mess to put locks everywhere. All he wanted was to simply freeze task-switching
for a moment so he could loop over the mapping and have it be in a consistent
state from the start of the loop to the end. His situation was further
complicated because the looping construct was buried in library code which used
iterkeys() instead of keys() -- IOW, the code bombed if the mapping changed
during iteration
While the guy had an odd design, the generalization was clear. Sometimes you
want to make one little section uninterruptable and don't want to put locks
around everything that touches a resource. If the resource access occurs in
fifty places throughout your code and you only need one little section to have
uninterrupted access, then the lock approach requires way too much effort.
Further, if you miss putting locks around any one of the accesses, you lose
reliability. Also, with locks scatterred all over the place, it is not easy to
tell at a glance that you haven't introduced the possibility of dead-lock. In
contrast, with the temporary suspension of thread-switching, it is pretty easy
to look inside the uninterruptable block to make sure that none of the
statements block. Why make life unnecessarily hard.
Raymond
More information about the Python-Dev
mailing list