[Zope] system requirements

[Matthew T. Kromer]

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/