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

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


[Phillip J. Eby]
> Well, I'm showing my age here, but in the good ol' days of the 8086
> processor, I recall it frequently being used to describe a block of
> assembly code which ran with interrupts disabled - ensuring that no task
> switching would occur.

According to Wikipedia's current article on "critical section" (which
is pretty good!), that still may be common usage for kernel-level
programmers.  "The rest of us" don't get to run privileged
instructions anymore, and in Wikipedia terms I'm talking about what
they call "application level" critical sections:

    http://en.wikipedia.org/wiki/Critical_section

A little Googling confirms that almost everyone has the
application-level sense in mind these days.

> Obviously I haven't been doing a lot of threaded programming *since*
> those days, except in Python.  :)

And for all the whining about it, threaded programming in Python is
both much easier than elsewhere, _and_ still freaking hard ;-)

>> 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

> That doesn't seem like a very useful definition, since it describes any
> piece of code that's protected by a statically-determined mutex.  But you
> clearly have more experience in this than I.

As I tried to explain the first time, a mutex is a common
implementation technique, but even saying "mutex" doesn't define the
semantics (see the original msg for one distinction between
cross-thread and cross-process exclusion).  There are ways to
implement critical sections other than via a mutex.  The "common
meaning" I gave above tries to describe the semantics (visible
behavior), not an implementation.  A Python-level lock is an obvious
and straightforward way to implement those semantics.


More information about the Python-Dev mailing list