[Python-Dev] RE: [Thread-SIG] Re: marking shared-ness

[Greg Stein]

On Fri, 21 Apr 2000, Brent Fulgham wrote:
>...
> The problem is that having to grab the global interpreter lock
> every time I want to manipulate Python objects from C seems wasteful.
> This is perhaps more of a "interpreter" issue, rather than a
> thread issue perhaps, but it does seem that if each thread (and
> therefore interpreter state from my perspective) kept internal
> track of itself, there would be much less lock contention as one
> interpreter drops out of Python into the C code for a moment, then
> releases the lock and returns, etc.
> 
> So I think it's possible that free-threading changes might provide
> some benefit even on uniprocessor systems.

This is true. Py_BEGIN_ALLOW_THREADS and Py_END_ALLOW_THREADS become null
macros. Your C extensions operate within their thread of execution, but
have no central lock to worry about releasing before they block on
something.

And from an embedding standpoint, the same is true. You do not need to
acquire any locks to start manipulating Python objects. Each object
maintains its own integrity.

Note: embedding/extending *can* destroy integrity. For example, tuples
have no integrity locking -- Python programs cannot change them, so you
cannot have two Python threads breaking things. C code can certainly
destroy things with something this simple:

    Py_DECREF(PyTuple_GET_ITEM(tuple, 3));
    PyTuple_SET_ITEM(tuple, 3, ob);

Exercise for the reader on why the above code is a disaster waiting to
happen :-)

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/