[Python-Dev] PyFAQ: thread-safe interpreter operations
Robert Brewer
fumanchu at amor.org
Tue Nov 21 20:29:22 CET 2006
Martin v. Löwis wrote:
> Armin Rigo schrieb:
> > I think this list of examples isn't meant to be read that
> > way. Half of them can invoke custom methods, not just the
> > two you mention here.
>
> Ah, so it's more about Consistency (lists not being corrupted)
> than about Atomicity (operations either succeeding completely
> or failing completely). Perhaps it's also about Isolation (no
> intermediate results visible), but I'm not so sure which of
> these operations are isolated (given the callbacks).
It's not "about" any of those things, because we're not discussing transactional models. The FAQ entry is trying to list statements which can be considered a single operation due to being implemented via a single bytecode. By eliminating statements which use multiple VM instructions, one minimizes overlapping operations; there are other ways, but this is easy and common, and is an important "first step" toward making a container "thread-safe". You're bringing in other, larger issues, which is fine and should be addressed in a larger context. But the FAQ isn't trying to address those.
The confusion arises because transactional theory uses "atomic transaction" in a much narrower sense than language design uses the phrase "atomic operation" (see http://en.wikipedia.org/wiki/Atomic_operation for example--it includes isolation and consistency). And the FAQ entry is only addressing the "isolation" concern; whether or not a given operation can be interrupted/overlapped. Those who design thread-safe containers benefit from such a list. Yes, they must also make sure no Python code (like __del__ or __setattr_, etc) is invoked during the operation; others have already pointed out that by using builtins, this can be minimized. But that "second step" doesn't negate the benefit of the "first step", eliminating statements which require multiple VM instructions.
Robert Brewer
System Architect
Amor Ministries
fumanchu at amor.org
More information about the Python-Dev
mailing list