Question about Python threads

[Chris Bailey]

"Artur Biesiadowski" <abies at pg.gda.pl> wrote in message
news:akguhv$1i257h$1 at ID-107541.news.dfncis.de...
> Gerhard Häring wrote:
>
> > In Python, everything is an object, including ints, ... so two threads
> > manipulating the refcount of an object at the same time will certainly
> > crash the interpreter sooner or later. AFAIK Java objects don't have
> > refcounts, right?
>
> No, it does not use refcounts, it is not a good idea for anything else
> than niche languages or special objects (for example strings).
>
> JVM has quite well defined semantics in presence of multiple threads
> (including multiple processors). There are some small problems with
> multiprocessor cache and synchronization - java memory model is in
> process of being relaxed to allow optimized implementation.

Correct. Currently the only form of locking available is using
synchronisation. The option of using barriers is not available in Java.

> Anyway, in java, you can modify anything from as many threads as you
> like. Of course, without synchronization, effect of operation is
> unexpected - but result will be legal. This means that if two threads
> modify int field =1 by adding 1 to it, you can get 3 or 2 as a result,
> but not 1, -1 or JVM crash.

Correct. As is the case in any language. If there is no locking on data and
multiple threads are acting on it, there is no guarantee in which order the
data manipulation will occurr.
Java, however, will no crash.

> For object pointers it is not a problem at all - they are just
> overwritten by competing threads, but everything still works, as
> referencing/dereferencing object does not imply any other actions done
> by JVM.
>
> Of course there are few tricky parts, especially concerning GC. If GC
> tries to run in presence of mutating threads, it potentially COULD crash
> JVM. But this is illegal and no JVM behaves like that. Simpliest
> solution is to stop all threads (either in place or by advancing them to
> special trap points) and only then performing GC (so GC is
> single-threaded on one processor - which is a problem on multi-way
> boxes, performance wise). More complicated solutions include
> generations, marking written pages of memory, etc.

Now you are into the world of supposition. You have started talking about
how a given JVM is implimented, and this has nothing what so-ever to do with
the JVM specification, or the Java language. And yes, there are currently
JVMs that use a GC algorithm that allows it to run concurrently to mutator
threads.
This is also completely irrelevant to a discussion of Java locking/memory
model.

> Generally, JVM is not allowed to crash in ANY situation. Of course, real
> life is less perfect and JVMs are known to crash sometimes - but this is
> mostly when interacting with native libraries, performing some kind of
> complicated graphics or working with gigabytes of memory used.

Anytime a JVM crashes running pure Java code (without JNI) is a JVM bug.

>
> Artur
>