GIL in alternative implementations

Pascal Chambon pythoniks at gmail.com
Fri May 27 17:21:46 EDT 2011


Hello everyone,

I've already read quite a bit about the reasons for the GIL in CPython, 
i.e to summarize, that a more-fine graine locking, allowing real 
concurrency in multithreaded applications, would bring too much overhead 
for single-threaded python applications.

However, I've also heard that other python implementations (ironpython, 
jython...) have no GIL, and yet nobody blames them for performance 
penalties that would be caused by that lack (I especially think about 
IronPython, whose performances compare quite well to CPython).

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.

Do these VMs have some GIL-like limitations, that aren't spoken about ? 
Are there functionings completely different from the CPython VM, so that 
the question is not relevant ? Do people consider that they always 
concern multithreaded applications, and so accept performance penalties 
that they wouldn't allow in their CPython scripts ?

I think you in advance for your lights on these questions.

Regards,

Pkl

[[ Important Note: this is a serious question, trolls and emotionally 
disturbed persons had better go on their way. ]]

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20110527/64e45bb7/attachment.html>


More information about the Python-list mailing list