Date: Tue, 1 Feb 2000 19:24:32 -0800 From: Alfred Perlstein <bright@wintelcom.net> To: Chee Wei Ng <scip7050@yahoo.com> Cc: smp@freebsd.org Subject: Re: MPrellock_edx Message-ID: <20000201192431.J24609@fw.wintelcom.net> In-Reply-To: <20000202022404.5985.qmail@web123.yahoomail.com>; from scip7050@yahoo.com on Tue, Feb 01, 2000 at 06:24:04PM -0800 References: <20000202022404.5985.qmail@web123.yahoomail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
* Chee Wei Ng <scip7050@yahoo.com> [000201 19:00] wrote: > Hi Alfred, > > --- Alfred Perlstein <bright@wintelcom.net> wrote: > > * Chee Wei Ng <scip7050@yahoo.com> [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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000201192431.J24609>