[Python-Dev] Threading idea -- exposing a global thread lock (original) (raw)

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

reslock = Lock() res = ... with locked(reslock): dosomething(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