[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.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
