Question about Python threads

Patricia Shanahan pats at
Wed Aug 28 23:30:28 CEST 2002

Artur Biesiadowski wrote:
> 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?
> 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.

No it does not, if the caches maintain coherence among themselves.

> Some pointers about fixing java memory model (more than just this
> synchronization flush):
> 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.

All Sun SPARC systems run in TSO, the strictest of the three memory
models defined in the SPARC Architecture Manual, not RMO, which is the
weakest of them.


More information about the Python-list mailing list