GIL in alternative implementations

Ian Kelly ian.g.kelly at gmail.com
Tue Jun 7 16:22:50 EDT 2011


On Tue, Jun 7, 2011 at 11:51 AM, Ethan Furman <ethan at stoneleaf.us> wrote:
>> I'm not sure where he gets the idea that this has any impact on
>> concurrency, though.
>> What if f has two calls to self.h() [or some other function], and self.h
> changes in between?
>> Surely that would be a major headache.

I could imagine a problem similar to the non-atomic increment example
arising from continuations.
from functools import partial
def g(value):
 print(value)
 return partial(g, value+1)
f = partial(0)
for i in range(10000):
 f = f()
With a single thread, this will print the numbers 0 to 9999. With
multiple threads executing the loop simultaneously, not so much. Note
that this is not the same example as the non-atomic increment, because
making "value += 1" atomic would not fix this. You would have to make
the entire function call (and subsequent assignment) atomic to make
this concurrent.
Cheers,
Ian


More information about the Python-list mailing list

AltStyle によって変換されたページ (->オリジナル) /