Foo_ (foo@nomail.com) on 10/28/06 wrote:
---------------------------
>Tzvetan Mikov (tzvetanmi@yahoo.com) on 10/26/06 wrote:
>---------------------------
>>(As far as I know, Perl, Python & friends use a global lock arround all data accesses
>>- which is of course much worse than having read barriers)
>
>Python actually uses a Global Interpreter Lock (GIL), which means you can't execute
>bytecode from two threads concurrently. Libraries implemented in C can explicitly
>release the GIL if they find it useful (for example the I/O libraries).
>
>However, Python does not use locks around data accesses at all. It could therefore
>be bitten by the problems exposed in this thread. But since Python is relatively
>slow and does a lot of things when it accesses non-local variables, I suppose those problems statistically never happen.

Perhaps I misunderstand what a global interpreter lock means (I don't have a lot of practical experience with CPython). As far as I can tell, a global interpreter lock elliminates the problem completely. Actually it enforces a much stricter memory model: all writes will always be seen by all threads in the order they occured. Additionally it can guarantee atomicity for certain operations like increments, etc.

This raises an interesting question. I am pretty sure that neither Jython nor IronPython use a global interpreter lock. That means that the have essentially the Java memory model (I assume that the .NET model is very close to it).

So, the memory model of the clasic Python is just an accident of the implementation, not a feature of the language. I wonder what percentage of the existing Python code would break because of this if executed under Jython or IronPython. Perhaps very little, if there are no multithreaded apps. This seems like a good reason to discourage threads.

>It's the view of Python developers that using threads shouldn't be encouraged (although
>Python does provide the necessary APIs to do it: locks, condition variables...).
>For example, the main network programming framework, Twisted Python, is single-threaded and based on an event-loop.
>

Makes sense. With a global lock a multithreaded application will always be slower than a single threaded one, no matter how many CPUs you have.