Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #7181

Re: GIL in alternative implementations

Show key headers only | View raw

On Tue, Jun 7, 2011 at 11:51 AM, Ethan Furman <ethan@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

Back to comp.lang.python | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Re: GIL in alternative implementations Carl Banks <pavlovevidence@gmail.com> - 2011-06-07 10:08 -0700
  Re: GIL in alternative implementations Ethan Furman <ethan@stoneleaf.us> - 2011-06-07 10:51 -0700
  Re: GIL in alternative implementations Ian Kelly <ian.g.kelly@gmail.com> - 2011-06-07 14:22 -0600
  Re: GIL in alternative implementations Ian Kelly <ian.g.kelly@gmail.com> - 2011-06-07 14:23 -0600

csiph-web