I've talked before about the speed advantage that Python builtins have . But speed isn't the only way that Pythonprivileges things written at the C level; as dict.setdefault() illustrates , Python makes a usefulatomicity guarantee for them that it does not make for methods writtenin Python itself.
Does this guarantee matter? I think that it does, because it issimultaneously useful and cheap. A concurrent program can avoid lockingwhen dealing with shared data built carefully from builtin types, andduplicating the effects
A comment on the previous entry about how builtins are atomic asked a really good question:
Is there actually a guarantee in CPython that they're atomic,or is that a side-effect of implementation?
There are two answers, at least in my opinion. The legalistic answeris that there is no guarantee at all, because there's nothing inthe documentation. But this is because the CPython documentationdoesn't talk about concurrency issues at all; even the thread moduledocumentation doesn't really say anything
Update : I'm wrong about this. See the comments for more details.
Since I alluded to this issue recently , hereis the problematic interaction between yum's versionlock plugin, whichis used to 'pin' a particular version of a package so that it won't getupgraded, and yum's installonly feature, which is used by Red Hat andFedora to keep only some number of kernels (by default 2).
Here is the problem sequence:
One of the things I do in the back of my mind is to keep my eyes openfor Python things that could be useful for concurrency (especiallysince I still have a concurrency problem that Ihave to solve one of these days). Because of what the GIL protects , one of the useful things to look for isinteresting operations on builtin types.
All of which is a roundabout way of saying that it recently struckme that dict.setdefault() is a limited test-and-set operation .All
HK
SF
New / Update
