Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!selfless.tophat.at!newsfeed.xs4all.nl!newsfeed5.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=N+pTN/B8a685jZttdwv9XjNwKzXGq0ZCq7t0suJH00XBPWjYGtUJ9A30Jl46zqLGUl 3DwqS4ZyQcSJBN8ntTH6Gy6tKJfKZ+EESgUzuurr5K9Hlk0C/9oaWAnJXcVkGXtx+931 c532mxiFXOtbhRtagNudaspqE+9WnLj1Ukc5M=
MIME-Version: 1.0
In-Reply-To: <4DE015EA.4040600@gmail.com>
References: <4DE015EA.4040600@gmail.com>
Date: Sat, 28 May 2011 13:06:43 +1100
Subject: Re: GIL in alternative implementations
From: Daniel Kluev <dan.kluev@gmail.com>
To: python-list@python.org
Content-Type: text/plain; charset=ISO-8859-1
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.2185.1306548406.9059.python-list@python.org>
Lines: 47
NNTP-Posting-Host: 82.94.164.166
Xref: x330-a1.tempe.blueboxinc.net comp.lang.python:6446

> So I'd like to know: how do these other implementations handle concurrency
> matters for their primitive types, and prevent them from getting corrupted
> in multithreaded programs (if they do) ? I'm not only thinking about python
> types, but also primitive containers and types used in .Net and Java VMs,
> which aren't atomic elements either at an assembly-level point of view.

Well, they definitely have some shortcomings:

test.py:

from threading import Thread
class X(object):
    pass
obj = X()
obj.x = 0

def f(*args):
   for i in range(10000):
       obj.x += 1

threads = []
for i in range(100):
    t = Thread(target=f)
    threads.append(t)
    t.start()

for t in threads:
    while t.isAlive():
        t.join(1)

print(obj.x)

> python test.py
1000000
> pypy test.py
1000000
> jython-2.5 test.py
19217
> ipy test.py
59040

Not that this thing is reasonable to do in real code, but cpython and
other implementations with GIL at least give you some safety margin.

-- 
With best regards,
Daniel Kluev