(no subject)

[Michael Chermside]

Ype writes:

For the namespaces in Jython this 'Python internal thread safety'
is handled by the Java class:

http://www.jython.org/docs/javadoc/o...StringMap.html

which has almost all of it public methods Java synchronized:

http://cvs.sourceforge.net/viewcvs.p...re/PyStringMap.
java
Thinking about it: is this the Jython parallel of CPython's
Global Interpreter Lock, the famous GIL?

No.

The GIL has the unfortunate disadvantage that it prevents multiple
processor machines (or other modern architechures) from processing
multiple bytecodes simultaneously in different threads. Jython does
not have this limitation.

-- Michael Chermside

[Alan Kennedy]

Michael Chermside wrote:

The GIL has the unfortunate disadvantage that it prevents multiple
processor machines (or other modern architechures) from processing
multiple bytecodes simultaneously in different threads. Jython does
not have this limitation.

Michael,

That's the first definitive statement I've ever read about Jython not
being limited by a GIL on multi-processor machines.

Would the following statements be correct?

1. CPython has a Global Interpreter Lock (GIL), which allows only one
thread to execute python code at a time. This "macro-level" of locking
was chosen because empirical evidence from experimental
implementations (a long time ago, in a galaxy far, far, away) showed
that it gave better performance than approaches using more
fine-grained locking, i.e. object-level locking.

2. Jython is implemented on top of java, which has built-in support
for fine-grained locking of individual objects. Therefore, the jython
implementers chose not to use a GIL, but instead to rely on the
fine-grained locking facilities of the Java platform to protect object
integrity. So jython programs support simultaneous execution of
multiple jython threads on multiple processors (obviously assuming the
Java VM on which it is running is capable of migrating threads to
other processors).

I know I could find out the answer to this question by going directly
to the jython source, but I unfortunately don't have the time. Also, I
don't actually *need* to know the answer, since I haven't yet needed
the horsepower of a mutli-processor box. But the question is
theoretically interesting, and probably of practical interest to many
readers of c.l.py.

And if the above statements are true, then I'm sure we're going to see
an interesting discussion of why fine-grained locking is fast enough
in java, but not fast enough in C >;-)

regards,

--
alan kennedy
-----------------------------------------------------
check http headers here: http://xhaus.com/headers
email alan: http://xhaus.com/mailto/alan

[Peter Hansen]

Alan Kennedy wrote:

Would the following statements be correct?
1. [snip]
2. Jython is implemented on top of java, which has built-in support
for fine-grained locking of individual objects. Therefore, the jython
implementers chose not to use a GIL, but instead to rely on the
fine-grained locking facilities of the Java platform to protect object
integrity.

You seem to think there is a "Jython runtime interpreter" in the same
way there is one for CPython... Are you aware that Jython compiles
your Python source to Java bytecode?

-Peter

[Andrew Dalke]

Alan Kennedy:

Would the following statements be correct?

1. CPython has a Global Interpreter Lock (GIL), which allows only one
thread to execute python code at a time. This "macro-level" of locking
was chosen because empirical evidence from experimental
implementations (a long time ago, in a galaxy far, far, away) showed
that it gave better performance than approaches using more
fine-grained locking, i.e. object-level locking.

I suspect it was done first because it was the easiest to do. Then
there was the free-threaded version, which provided the empirical
evidence.

Andrew
da***@dalkescie ntific.com

[Alan Kennedy]

[Alan Kennedy]

Jython is implemented on top of java, which has built-in support
for fine-grained locking of individual objects. Therefore, the jython
implementers chose not to use a GIL, but instead to rely on the
fine-grained locking facilities of the Java platform to protect object
integrity.

[Peter Hansen] You seem to think there is a "Jython runtime interpreter" in the same
way there is one for CPython... Are you aware that Jython compiles
your Python source to Java bytecode?

Compiles it to Java bytecode, which makes calls against a python
runtime which has been implemented in Java .....

All calls into the jython runtime require that the code execution be
associated with a PySystemState object, which keeps track of
"interprete r state" for the context in which the code is running
.......

http://www.jython.org/docs/javadoc/o...stemState.html

So jython bytecode *is* executed by a jython interpreter, which is an
interpreter in all but name ......

The last link in the chain is the PythonInterpret er object, which
wraps the above, and provides some simple services to simplify using
the "interprete r".

http://www.jython.org/docs/javadoc/o...terpreter.html

From what I can see, jython has pretty much, class for class, the same
structure as the cpython interpreter .....

--
alan kennedy
-----------------------------------------------------
check http headers here: http://xhaus.com/headers
email alan: http://xhaus.com/mailto/alan