Date: Sun, 2 Feb 1997 15:50:45 -0500 From: "David S. Miller" <davem@jenolan.rutgers.edu> To: terry@lambert.org Cc: terry@lambert.org, michaelh@cet.co.jp, netdev@roxanne.nuclecu.unam.mx, roque@di.fc.ul.pt, freebsd-smp@freebsd.org, smpdev@roxanne.nuclecu.unam.mx Subject: Re: SMP Message-ID: <199702022050.PAA19542@jenolan.caipgeneral> In-Reply-To: <199702022042.NAA08516@phaeton.artisoft.com> (message from Terry Lambert on Sun, 2 Feb 1997 13:42:32 -0700 (MST))
next in thread | previous in thread | raw e-mail | index | archive | help
From: Terry Lambert <terry@lambert.org> Date: Sun, 2 Feb 1997 13:42:32 -0700 (MST) Are you claiming that CPU2 would see the write of CPU1's cache line in all cases, and invalidate it's own cache line? Isn't there a potential race? I know it's unlikely, but it exists, right? This is the classic "Writeback Cancellation Requirement", and all cache coherency hardware implementations do have to deal with it somehow. Check out section 7.10.3 of the UltraSparc Programmers Manual, in the "UltraSPARC-I External Interfaces" chapter to see how one implementation happens to deal the race very nicely. The P_Reply and S_Reply signal synchronization rules are extremely clever here. ---------------------------------------------//// Yow! 11.26 MB/s remote host TCP bandwidth & //// 199 usec remote TCP latency over 100Mb/s //// ethernet. Beat that! //// -----------------------------------------////__________ o David S. Miller, davem@caip.rutgers.edu /_____________/ / // /_/ ><
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199702022050.PAA19542>