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