GIL in alternative implementations

[John Nagle]

On 5/27/2011 7:06 PM, Daniel Kluev wrote:
>> 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.

   "+=" is not guaranteed to be atomic in most languages.  Some
C and C++ implementations have "atomic_inc", etc., which is guaranteed
to execute as an atomic operation.

   How do most safe languages handle concurrency? For the unboxed 
primitive types, like numbers, the hardware handles it. For
memory allocation, there's a lock.  Most don't allow patching code
on the fly.  Concurrent garbage collection prevents deleting
something if there's a pointer to it anywhere.  This was all worked
out for LISP and SELF decades ago.

   Python allows patching code while the code is executing.  This
implies a sizable performance penalty, and causes incredible
complexity in PyPy.

					John Nagle