Critical sections and mutexes

[David Bolen]

<brueckd at tbye.com> writes:

> Should the GIL be removed someday down the road, *all* multithreaded apps
> would become suspect and overdue for a thorough review.

Perhaps multithreaded programs that have made assumptions, but to be
honest, anything I've written is always protecting itself from its use
of any shared resources (whether internal or system) and I wouldn't
expect any problems should the GIL be removed.

> 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 - other than the same risk they
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.

Who will undoubtably be affected are extension writers, and the core
would probably have to automatically allocate an extension-global lock
per extension (or one for all extensions) to ensure only one Python
thread can be in the extension(s) at a time, at least for legacy
support.

> the interpreter. Maybe it's just me, but Guido et al have gone to great
> lengths to make it nearly impossible to do that (and when it happens, it's
> considered a bug and is fixed ASAP). The GIL is what lets multi-threaded
> Python programs still behave like Python programs should.

Well, to some extent that's true, but it's hardly the only way to do
it.  It's just a poor man's global lock around an entire interpreter.
Safe, but also inefficient.  Whether resources will become available
to work on more fine grained locking for better efficiency is
questionable, but I'd certainly be in favor of any work in that
direction.

--
-- David
-- 
/-----------------------------------------------------------------------\
 \               David Bolen            \   E-mail: db3l at fitlinxx.com  /
  |             FitLinxx, Inc.            \  Phone: (203) 708-5192    |
 /  860 Canal Street, Stamford, CT  06902   \  Fax: (203) 316-5150     \
\-----------------------------------------------------------------------/