Matt Hamilton wrote:

On Tue, 4 Jun 2002, Matthew T. Kromer wrote:

...

All Python data structures are protected by this singular lock. Locking is thus very coarse grained, but fairly efficient -- were every data structure to have its own lock, the overhead of locking would become prohibitive.

Every action within the interpreter with a few very rare exceptions requires the GIL to be held by the invoking thread.

Matt, OK, thanks for the info -- I suspected this were the case. We have been doing a few tests with python/Zope on multi-processor machines (Sun boxes mainly). One question that continually gets asked is: "How does Java handle this?". Since Sun tout java so much, you would expect them to have solved most of the issues of scalability of java on their own hardware. So from this I am guessing that Java has a finer-grained locking model. Any ideas?

-Matt

Hmm. I'm not a Java guru. I'll give you what I think is a likely answer, but recognize that it's by no means authoritative. I *think* Java uses a serializable base class to indicate objects which must be serially invoked. Java provides (as does Python) threading base objects to provide mutual exclusion, semaphores, and other signal handling. The JVM thus handles primitive mutexes etc when executing bytecodes based on data gathered by the compiler. Python's use of the GIL is *heavily* geared towards how the C runtime for Python works. Low level primitive operations in Java are not (to my knowledge) exposed to any C API. Java presumably uses thread-based memory allocators to reduce inter-thread contention for memory allocation. Beyond that, I can't tell you how precise the JVM model is for things like reference count handling. If you do not use refcounts, but instead do cyclic garbage collection, you can structure things much differently -- ie, if I wanted to do gc-only deallocations, the I could make the JVM 'quiesce' each thread, then start the GC when each thread is suspended at a "safe" point (i.e. inside an API call) here they would not have the ability to alter memory state while the GC is running. Because I don't know much about what a JVM exposes to a C coroutine, I can only speculate about those details. In Python, a C module can pretty much alter the interpreter state at will with various API calls. The GIL make the programming of thread-safe extensions much less danger-prone. It is vaguely possible to envision a Python without a GIL (I think Christian Tismer may have created one) however, a GIL-less Python would have different performance characteristics and may impose some additional programming constraints not present in the current language. -- Matt Kromer Zope Corporation http://www.zope.com/