what's the point of rpython?

[Ross Ridge]

Ross Ridge <rridge at csclub.uwaterloo.ca> writes:
> The same cache coherency mechanism that prevents ordinary "unlocked"
> instructions from simulanteously modifying the same cache line on
> two different processors also provides the guarantee with "locked"
> instructions.  There's no additional hardware locks involved, and no
> additional communication required.

Paul Rubin  <http://phr.cx@NOSPAM.invalid> wrote:
>The cache coherency mechanism is what Scott described as
>"communicat[ing] to other processors that it (and it alone) owns the
>increment target".  The cache coherency mechanism is not a trivial
>thing at all.  It introduces its own hazards and delays, and it is
>getting more complicated all the time as processors and caches get
>faster and larger.

*sigh*  Could you please just read what I wrote above?  The LOCK prefix
makes NO DIFFERENCE to anything you mentioned.  When current CPython
implementation increments a referernce count, it doesn't use the LOCK
prefix, but the cache line modified by the instruction still has to be
owned by the processor.  If it did use the LOCK prefix there would be
no change in how how the cache coherency mechanism worked.  There'd be
no additional complications, hazards or delays in how the processor
communicates with other processors.

					Ross Ridge

-- 
 l/  //	  Ross Ridge -- The Great HTMU
[oo][oo]  rridge at csclub.uwaterloo.ca
-()-/()/  http://www.csclub.uwaterloo.ca/~rridge/ 
 db  //