[pypy-dev] Thinking about the GIL

hyarion at iinet.net.au hyarion at iinet.net.au
Fri Mar 18 01:44:41 CET 2011

On Thu Mar 17 21:30 , Laura Creighton  sent:

>In a message of Thu, 17 Mar 2011 13:18:07 +1100, William ML Leslie writes:
>>Where did you want this discussion to go, Laura?  It looks like you
>>wanted to talk about the specific problems that need to be dealt with
>>while removing the GIL, but it seems to have disintegrated into the
>>same "concurrency model X is better than concurrency model Y" free for
>>all that regularly seems to happen on this list.  Regardless of the
>>API that runtimes written with the translation toolkit may provide,
>>getting rid of the GIL is a precursor to the implementations of most
>>of these models.
>>William Leslie
>I'm at a Sprint at PyCON, as are many of the people I think would be
>best at answering these specific questions.   So it is not surprising
>that they are not answering them now.  I, myself, am personally interested
>in finding out how languages I have never looked at do these things,
>because I expect it to influence how one gets rid of the GIL.  I was
>hoping to have an insight as to how one could avoid going the route
>of reimplementing fine grained locks everywhere, pervasively, all
>through the codebase.  But all I am seeing now is more evidence that
>this is impossible.

This may be a dumb question, but has anyone considered software transactional memory 
for this sort of thing? My experience comes from the implementation side of STM in a 
very different language to (R)Python, but it seems like this might be a reasonable 
fir for STM's strengths. The GIL gives you a serial execution order of bytecodes, 
with no particular guarantees about which order (because if it matters there should 
be application level concurrency control). Wrapping each bytecode in an STM 
transaction would give you an as-if-serial execution order, again with no guarantees 
about which order. You get transaction overheads instead of lock/unlock overheads, 
but some STM systems can be quite efficient for short transactions that rarely 

There'd be a lot of problems to solve, of course. But has anyone already considered 
this and figured out that it's impossible or impractical?

-- Ben

More information about the Pypy-dev mailing list