Date: Tue, 23 Nov 1999 12:02:01 -0800 (PST) From: Alfred Perlstein <bright@wintelcom.net> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: Alan Cox <alc@cs.rice.edu>, Poul-Henning Kamp <phk@critter.freebsd.dk>, Peter Wemm <peter@netplex.com.au>, Tommy Hallgren <thallgren@yahoo.com>, freebsd-smp@FreeBSD.ORG Subject: Re: Matt's new unlock optimiazation Message-ID: <Pine.BSF.4.21.9911231156020.4557-100000@fw.wintelcom.net> In-Reply-To: <199911231901.LAA10726@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 23 Nov 1999, Matthew Dillon wrote: > :What Linus says is definitely true of non-x86 architectures, > :such as Alpha, but I had thought (not to be confused with > :"know for a fact") that the x86 was "sequentially > :consistent", making Matt's optimization legal. > : > :I've definitely seen the statement in the Intel manuals > :that writes are not reordered. Thus, if the > :program on processor 1 writes X to location A followed > :by Y to location B, then processor 2 is guaranteed to > :see X in A (and not some old value) if it's seen Y in B. > > Yes, that's what I thought too. Writes are not reordered, > but remember that pentiums do speculative reads and out of > order instruction execution as well. Apparently pentiums also > do write buffering (rather then write to the cache synchronously). > > http://developer.intel.com/drg/pentiumii/appnotes/831.htm > > The above says: > > * writes are ordered > > * reads do not pass *conflicting* writes, which means they > can pass non-conflicting writes. BROKEN!!!!!!! > > * Instructions may execute out of order (if non conflicting) > > * Writes can be buffered -- that is, the pending writes > are pending going INTO the cache and not synchronously > written to the cache as they are on, say, the later MIPS cpus. > > What a grade-A screwup by Intel. Extremely annoying at the very least. > Gimme a MIPS chip any day. I'm a bit confused by this, I take it to mean that there's really nothing wrong with the lock behavior however, if there are outstanding memory transactions to handle then they may actually be done after we've released the lock by the CPU that's released it. And that those memory operations rely on the mutual exclusion of the lock, so basically you have this sort of window: CPU a (has lock) CPU b (wants lock) mem write A mem read B mem write C RELEASE lock GOT lock A, B C aren't garanteed to be complete at this point and could be committed to memory at any point following the lock release? Is that correct? -Alfred (who still needs his morning pot of coffee) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.9911231156020.4557-100000>