Question about Python threads

[Chris Bailey]

"Artur Biesiadowski" <abies at pg.gda.pl> wrote in message
news:akj0u6$1ijj5n$1 at ID-107541.news.dfncis.de...
> Patricia Shanahan wrote:
>
> >>Problems was with synchronization being defined too strict. To implement
> >>it, full cache flush would be required on each synchronization. No JVM
> >
> > I don't see the reasons for this. Could you explain further?

Neither do I. How synchronisation is carried out is dependent on the JVM
implimentation, and therefore on the underlying architecture that it runs
on.
Sun SPARC TSO runs under a very strong cache coherency model, and enforces
cache coherency itself, therefore a 'full cache flush' isn't required.
>
> People are expecting (because of the spec) that any synchronization will
> synchronize entire world. So if I modif any number of fields etc, I can
> then do
>
> synchronized(new Object()) {}
>
> and expect to get all variables, including ones modified potentially
> hour ago to be propagated to all threads on all processors. It requires
> writing all cache of given processor to main memory and invalidating
> caches for these pieces of memory for rest of processors. Latter part is
> not a big performance problem - former is.

Again, how this is carried out depends on the underlying architecture that
the JVM is running on.

> Some pointers about fixing java memory model (more than just this
> synchronization flush):
>
> http://jcp.org/jsr/detail/133.jsp
> http://gee.cs.oswego.edu/dl/cpj/jmm.html
> http://www.cs.umd.edu/~pugh/jmm.pdf
>
>
> Excerpt from last reference:
>
> -------------------------------------------------------
>
> 3.3 Coherence is difficult
> As noted above, the existing Java memory model enforces
> Coherence. Unfortunately, Coherence cannot be
> enforced on architectures such as Sparc RMO without
> memory barriers. The Sparc RMO doesn't not guarantee
> that reads of the same memory location will be
> executed in their original order. To enforce this, a
> load/load memory barrier is required between any two
> successive loads of the same memory location. It is unclear
> if any existing implementations of the Sparc RMO
> would actually violate Coherence.
> As mentioned earlier (Section 2.3), Coherence also
> interferes with a number of compiler optimizations.
>
>
> 3.4 Flushing memory is expensive
> The semantics of the lock and unlock actions in the
> JMM are that they cause a thread to flush all dirty
> variables from the thread's working memory (registers,
> cache, ...) to main memory, and a lock action also
> causes a thread empty all variables from the thread's
> working memory, so that they have to be reloaded from
> main memory before they can be used.
> Some have suggested that, particularly in a multiprocessor
> server, this will be expensive. An alternative
> would be to say that only memory accessed inside
> the synchronized block is flushed/emptied. This would
> probably be a good idea if you were designing a memory
> model from scratch, although more analysis is needed.
> However, people writing to the current memory model
> might expect that
> synchronized(unsharedObject) {}
> would have the effect of a memory barrier. Careful thought is required
> about the amount of existing code that would break if this change were
made.
> ------------------------------------------------------

Flushing the cache is only 'expensive' on weak cache coherency models. On
architectures running weak models there may be the 'cheaper' option of using
memory barriers - this is Java's current failing, that the user does not
have the option of using a barrier instead of a full blown lock. The problem
is that implimenting this moves away from the 'Write once, Run anywhere'
ideal of Java.

> Artur
>