Critical sections and mutexes

[brueckd at tbye.com]

On Thu, 25 Oct 2001, Cliff Wells wrote:

> Any CS book that discusses threading (in the general sense) will
> emphasize the need for locking shared resources.

But only because, in the general sense, you have to do that work yourself.
It's not that locking isn't happening, it's that someone is doing some of
it for you. A CS book that discusses memory management will cover
everything from heap strategies to allocation and deallocation - that does
not imply that you, the developer, will always need to do it though.

> However, it doesn't (and shouldn't) encourage you to adopt bad programming
> practices just because you can

Hold on... the definition of a "bad" programming practice is certainly not
universal. Not deleting memory you allocated is bad in C; that doesn't
make it bad in Python. Yes there are principles that apply to many
languages, after lots of multithreaded Python programs I've come to find
that "always use explicit locking" isn't one of them, that's all.

> (I _could_ use the variable x to hold an int, a string and a list at
> different times in the same function, but it would be bad).

This is baggage you're bringing with you from previous languages - we all
do this to one degree or another. Once again, though, what may be an
"always" rule in C is a good rule of thumb but not as strict in Python:

for line in open('ages.txt').readlines():
  name, age = line.strip().split()
  age = int(age)

"Always bad in language X" does not imply "Always bad in Python".

> I don't feel locking is a detail so much as a fundamental aspect of
> threading.

I'm not disagreeing with you, Cliff. At issue is the fact that it is so
fundamental that the interpreter already does some of it for you.

>  The fact that you can get away with it (in special cases) under
> current implementations of Python is not really a good reason to do it.

Do you explicitly close every file object you open? I sure don't. And when
the time comes that I do have to close the file myself, I certainly don't
feel that all those other times I'm getting away with something. It's just
how things work and it's very convenient.

> It's my feeling that making high-level code rely on low-level
> implementation details of an interpreter or compiler is always a bad
> idea

I wholeheartedly agree that reliance on low-level implementation details
can be a Bad Thing. I don't, however, see this as all that low-level (in
fact, always requiring explicit locking even on simple resource access
smacks of just the type of annoying task that Python helps you avoid).

The fact that the Python core is inherently thread-safe is a very
high-level concept, and is a fundamental part of threading support in
Python. It is completely in line with other housekeeping/safety features
of Python. That type of basic thread safety will not go away. The GIL
might, but its replacement would still be a threadsafe core, and so you'd
end up with the same thing.

-Dave