Question about Python threads

[Artur Biesiadowski]

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.


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.
------------------------------------------------------




Artur