Critical sections and mutexes

brueckd at tbye.com brueckd at tbye.com
Thu Oct 25 09:39:54 EDT 2001


On 25 Oct 2001, David Bolen wrote:

> > FWIW, I don't think the GIL will ever go away, or if it does, we'll end up
> > with something that gives the same behavior. Think about it: no GIL means
> > that a normal Python program (ie no extension modules in use) could crash
> > the interpreter.
>
> No it doesn't.  Obviously removing the GIL requires making the C core
> of Python threadsafe, thus it will internally use whatever locks or
> synchronization mechanisms are necessary around shared structures or
> processes.  You don't just stop using the GIL without any other
> changes.  The interpreter just won't be a single global lock.  Python
> scripts shouldn't have any risk at all

That's exactly my point: if the GIL goes away, its replacement will have
the same behavior. For example, today I can safely have two threads append
items to the same list "simultaneously". In your threadsafe Python core
implementation, the same will be true. In neither case do I need to
perform explicit locking on the list, while in C, for example, I'd have
to. This is precisely the type of "free thread safety" that I've been
talking about, and I'm in no way saying that this fulfills all your needs
all the time.

> have today through misuse of shared resources without locking , and
> yes those scripts that today make assumptions may run into trouble.
> But I just see that as the definition of a well-written threadsafe
> program.

So assuming the GIL is replaced by a threadsafe Python core, what will
break in my program with two worker threads appending to the same list?

-Dave





More information about the Python-list mailing list