[Python-Dev] Threading idea -- exposing a global thread lock

[Raymond Hettinger]

[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