Python GIL removal question

&#62;That is, if one processor writes to memory in a cache-line shared by another processor, they must stop whatever they are doing to synchronize the dirty cache lines with RAM. Thus, updating reference counts would flood the memory bus with traffic and be much worse than the GIL.<p>I dont' understand. Isn't this going to happen if you have multiple threads running even <i>if</i> the GIL is blocking them from running? I'm not a hardware expert, but I'm not sure how constant locking would prevent cache synchronization just because they weren't truly running in parallel.<p>I am fairly certain that constant synchronization(lock) because of the GIL would negatively impact cache performance, especially since well designed multithreaded applications avoid locking for as long as possible.

I find it terribly annoying when the solution to a language problem is "Write an extension". It's a cop-out.<p>Java, .NET, various Lisps, and I'm sure other systems that I don't know off the top of my head have solved the problem of true threading.

Can anyone shed light on where the GIL winds up hurting you?<p>According to this paper [1]: "Thus, in all cases, the single global lock semantics seem fundamentally compatible with both lock-based and transactional memory implementations."<p>[1] <a href="http://www.usenix.org/event/hotpar09/tech/full_papers/boehm/boehm_html/" rel="nofollow">http://www.usenix.org/event/hotpar09/tech/full_papers/boehm/...</a>

If you leave aside C-extensions and libraries, CPython is a pretty bad language for number crunching. This is just not the use-case it tries to solve. I am glad they favor simplicity over execution speed.<p>Removing the GIL might be useful for a faster implementation with JIT compiler though.

Reference counts could be stored separately from objects and migrated to the thread that modified it. Or several reference counts for the same object could be used. Has this been tried?

<i>If the GIL bites you, it's most likely a warning that your program is badly written, independent of the GIL issue.</i><p>Ah, that old line again.<p>Translation: <i>"We really don't like to even think about changing this crappy design that we started with in the first place, because we can just explain ourselves out of it by coming up with suitable language goals that don't actually require concurrent access to the interpreter. Not accessing the interpreter concurrently is one of our language goals because you can do </i>everything else<i>. So, if you think you still need to get rid of GIL then you're just a bad programmer and your programs are badly written because hey, we just defined the universe you're playing in."</i>

Sounds like typical denial a la Firefox memory usage or MySQL's early lacking that have to get eaten down the line.<p>Not that the case isn't well argued, but to claim that GIL isn't a fundamental limitation and a bad thing is silly.<p>A few years from now it will be like, "Oh, yeah.. that".

The most frustrating thing about Python is its community's complete denial about what a joke their concurrency situation is. Truth is python is not truly multi-threaded, and no, claiming that multi-process is the way to do parallel computation across the board is not a sane argument at all. It's religious zeal. My company is currently using it for web apps, and that's proving a pain (i.e. having to use proxy servers for database access to minimize connections across all the python process instances). Using python for anything more serious, like a message queuing system for example is even more prohibitive. People in charge should wake up and start taking serious steps about it. I guess PyPy is the biggest hope. Meanwhile in the JVM world..