(no subject)

[Michael Chermside]

Ype writes:[color=blue]
> 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:
>
>[/color]
http://cvs.sourceforge.net/viewcvs.p...re/PyStringMap.
java[color=blue]
>
> Thinking about it: is this the Jython parallel of CPython's
> Global Interpreter Lock, the famous GIL?[/color]

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]

Jython, GILs and object locking.

Michael Chermside wrote:[color=blue]
> 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.[/color]

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]

Re: Jython, GILs and object locking.

Alan Kennedy wrote:[color=blue]
>
> 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.[/color]

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]

Re: Jython, GILs and object locking.

Alan Kennedy:[color=blue]
> 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.[/color]

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
dalke@dalkescie ntific.com

[Alan Kennedy]

Re: Jython, GILs and object locking.

[Alan Kennedy][color=blue][color=green]
>> 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.[/color][/color]

[Peter Hansen][color=blue]
> 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?[/color]

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/org/python/core/PySystemState.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/org/python/util/PythonInterpreter.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