what's the point of rpython?

[Aahz]

In article <gl84uf$ju9$1 at rumours.uwaterloo.ca>,
Ross Ridge  <rridge at csclub.uwaterloo.ca> wrote:
>Scott David Daniels  <Scott.Daniels at Acm.Org> wrote:
>>
>>The opcode cannot simply talk to its cache, it must either go directly
>>to off-chip memory or communicate to other processors that it (and it
>>alone) owns the increment target.
>
>In fact all it does simply talk to its cache.  From the "Intel 64 and
>IA-32 Architectures Software Developer's Manual, Volume 3A: System
>Programming Guide, Part 1":
>
>	For the P6 and more recent processor families, if the area of
>	memory being locked during a LOCK operation is cached in the
>	processor that is performing the LOCK operation as write-back
>	memory and is completely contained in a cache line, the processor
>	may not assert the LOCK# signal on the bus. Instead, it will
>	modify the memory location internally and allow it's cache
>	coherency mechanism to insure that the operation is carried
>	out atomically. This operation is called "cache locking." The
>	cache coherency mechanism automatically prevents two or more
>	processors that have cached the same area of memory from
>	simultaneously modifying data in that area.
>
>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.

IIRC, it was Bruce Eckel I heard talking about discovering all kinds of
nasty Java thread bugs because cache coherency wasn't working the way the
Java developers thought it did....  This is apparently something very
difficult to get correct.
-- 
Aahz (aahz at pythoncraft.com)           <*>         http://www.pythoncraft.com/

Weinberg's Second Law: If builders built buildings the way programmers wrote 
programs, then the first woodpecker that came along would destroy civilization.