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

Tim Peters tim.peters at gmail.com
Tue Mar 14 20:21:14 CET 2006

[Raymond Hettinger]

FWIW, the new with-statement makes the above fragment even more readable:

with atomictransaction(): # do a series of steps without interruption

[Phillip J. Eby]

+1 on the idea, -1000 on the name. It's neither atomic nor a transaction. I believe that "critical section" is a more common term for what you're proposing.

No, there is no common term for this idea, no "standard" threading model supports it directly (which is bad news for portability, of course), and it's a Bad Idea to start calling it "critical section" here.

There is some variation in what "critical section" means, exactly, to different thread programming cultures, but in none does it mean:

a section of code such that, once a thread enters it, all other
threads are blocked from doing anything for the duration

The common meaning is:

a section of code such that, once a thread enters it, all other
threads are blocked from entering the section for the duration

which is a very far cry from getting blocked from doing anything.

In some thread cultures, "critical section" also implies that a thread won't migrate across processors (on a multi-CPU box) while that thread is in a critical section, and that's in addition to the "other threads are blocked from entering the section for the duration" meaning.

In some thread cultures, "critical section" isn't distinguished from the obvious implementation in terms of acquiring and releasing a mutex around the code section, but that gets muddy. For example, on Win32 using a native mutex actually implments a cross-process "critical section", while the term "critical section" is reserved for cross-thread-within-a-process but not-cross-process mutual exclusion.

More information about the Python-Dev mailing list