Critical sections and mutexes

[brueckd at tbye.com]

On 25 Oct 2001, David Bolen wrote:

> > 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.
>
> Ah, but Python's dynamicism can make it hard to predict when you're
> sure that you are executing within the core (say your code is handed a
> Python implemented object that just happens to look like a list), or
> especially when you can subclass the built-in types in 2.2.  Although
> I'd concede that if done right such other objects or subclasses ought
> to maintain the same sort of threadsafe contract as the built-in
> objects do, but that's harder to guarantee and I'm not sure I'd want
> to risk it when writing code for later maintenance.

Good point - every time I've relied on this behavior it has been in a
self-contained program rather than a library that I was making available
to someone else. In the library case I don't know how common the
"simultaneous access of a user-provided object" is, but in that case I'd
definitely agree that strict locking would be high on the list of things
to do to make sure the library is sufficiently robust.

-Dave