From owner-freebsd-smp Tue Feb 1 18:59: 3 2000 Delivered-To: freebsd-smp@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by builder.freebsd.org (Postfix) with ESMTP id 5A7D64022 for ; Tue, 1 Feb 2000 18:59:01 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.9.3/8.9.3) id TAA25953; Tue, 1 Feb 2000 19:24:32 -0800 (PST) Date: Tue, 1 Feb 2000 19:24:32 -0800 From: Alfred Perlstein To: Chee Wei Ng Cc: smp@freebsd.org Subject: Re: MPrellock_edx Message-ID: <20000201192431.J24609@fw.wintelcom.net> References: <20000202022404.5985.qmail@web123.yahoomail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20000202022404.5985.qmail@web123.yahoomail.com>; from scip7050@yahoo.com on Tue, Feb 01, 2000 at 06:24:04PM -0800 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * Chee Wei Ng [000201 19:00] wrote: > Hi Alfred, > > --- Alfred Perlstein wrote: > > * Chee Wei Ng [000201 17:31] wrote: > > > Hi, > > > > > > I would like to know why we need > > > lock > > > addl $0,0(%esp) /* see note above */ > > > for serialization. > > > > > > Could you show me an example for MP case where it may cause trouble if the > > > above lines are not added in it? > > > > > > Because I didn't see how instruction execution out of order come into the > > > picture since before any processors enter the Critical Section, it has to > > > acquire the mplock first, and acquire the mplock, you must 'LOCK' the bus > > cycle > > > to serialize the mplock flag to be read-modify-write, so I thought here > > will do > > > all the serialization as required. Unless, it could be something that may > > needs > > > to serialize for access before this. > > > > It's to ensure that memory ops scheduled _before_ the lock is released > > have been completed before the lock is actually released. > > > > Otherwise out of order memory writes can occur corrupting the state > > of protected variables. > > > > Imagine if a CPU releases a lock then a previously sheduled write on the > > _same_ cpu goes in several cycles after another processor aquires the > > lock. > > > > Since we aren't using a locked cycle to release the lock, we must _at least_ > > insert a barrier instruction to force correct ordering. > > > > -Alfred > > > > In this case, what you mean is that in order to update all the modified memory > for previous locked Critical Section, the barrier must be inserted for that > processor, right? > > For example, > > Initial value of A = 0xdeadc0de; > > Processor 1 Processor 2 > ----------- ----------- > MPgetlock_edx(mplock); > A = 0; > MPrellock_edx(mplock); > MPgetlock(mplock); > read A; > MPrellock(mplock); > > Suppose we do not have barrier instruction at MPrellock. > According to your explanation: > 1. The 'LOCK' instruction executed in MPgetlock at processor 2 after processor > 1 > released the mplock will not serialize the value of A, so when processor 2 got > the mplock and read A, it is possible to read 0xdeadc0de instead of 0. > 2. The write of A and mplock will not be in order, i.e. it could be > mplock == 0 and A == 0xdeadc0de, > after processor 1 released mplock and processor 2 wanted to acquire the mplock. > > The processor 1 might have follow the write order but the processor 2 will see > two values in out of order way. i.e. mplock will be updated before A. > > That's why processor 2 thought that it has the mplock and it's safe to read A, > but infact it is not. > > Is this what you mean? I'm wrong, see Matt Dillon's answer. -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message