Solving the problem of mutual recursion

Chris Angelico rosuav at gmail.com
Mon May 27 03:37:21 EDT 2013


On Mon, May 27, 2013 at 4:07 PM, Ian Kelly <ian.g.kelly at gmail.com> wrote:
> On Sun, May 26, 2013 at 10:36 PM, Peter Brooks
> <peter.h.m.brooks at gmail.com> wrote:
>> This makes complete sense - any atomic action should be atomic, so two
>> threads can't be doing it at the same time. They can be doing anything
>> else though.
>>
>> If two threads create a new object at the same time, for example,
>> there's potentially the problem that they'll get the same space, so
>> the object will be owned by both. To prevent this, the new object call
>> should be run in only one thread.
>>
>> If you have two objects running their methods on their own local
>> variables, then there's no potential for conflict, so there's no need
>> for them to be blocked.
>
> That's not the way it works. [snip details]

You're actually both saying the same thing, except that Peter went for
finer granularity than Ian and CPython did. CPython figures that, with
a refcounted heap, there's not a lot of point having separate mutex
locks for different operations. Other language interpreters have made
other choices. But Peter's analysis is still correct; it's just that
guarding it is simplified down to a binary state: either you have the
GIL, or you don't.

ChrisA



More information about the Python-list mailing list