From owner-freebsd-smp Tue Nov 23 11:42:57 1999 Delivered-To: freebsd-smp@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 7FFF41539C for ; Tue, 23 Nov 1999 11:42:55 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id LAA11156; Tue, 23 Nov 1999 11:42:11 -0800 (PST) (envelope-from dillon) Date: Tue, 23 Nov 1999 11:42:11 -0800 (PST) From: Matthew Dillon Message-Id: <199911231942.LAA11156@apollo.backplane.com> To: Alfred Perlstein Cc: Alan Cox , Poul-Henning Kamp , Peter Wemm , Tommy Hallgren , freebsd-smp@FreeBSD.ORG Subject: Re: Matt's new unlock optimiazation References: Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org :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 There is only one sequence of events that I believe can cause a problem, at least from my read of the app note: mem read A RELEASE lock (mem write X) In this case the instruction that runs 'mem read A' may be executed out of order from the instruction which writes X. Since location A does not conflict with the address of the lock, Intel's current spec allows the out of order execution to occur. I'm not sure how intel's speculative read works. They seem to imply that it goes into the cache, in which case cache coherency protocols will prevent a conflict. But if it goes into the execution unit's data buffer or if the instructions are actually executed out of order, we have a problem. Intel says that writes are ordered, so pending writes prior to release will not be a problem (no need for a locked instruction). We are left with mixed reads and writes. No sense taking any chances, it only costs us 55nS (on a P3-450). -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message