From owner-freebsd-smp  Tue Feb  1 17:24:44 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 4A6CE3FDC
	for <freebsd-smp@FreeBSD.ORG>; Tue,  1 Feb 2000 17:24:42 -0800 (PST)
Received: (from bright@localhost)
	by fw.wintelcom.net (8.9.3/8.9.3) id RAA23749;
	Tue, 1 Feb 2000 17:50:09 -0800 (PST)
Date: Tue, 1 Feb 2000 17:50:08 -0800
From: Alfred Perlstein <bright@wintelcom.net>
To: Chee Wei Ng <scip7050@yahoo.com>
Cc: freebsd-smp@FreeBSD.ORG
Subject: Re: MPrellock_edx
Message-ID: <20000201175008.F24609@fw.wintelcom.net>
References: <20000202010550.16864.qmail@web112.yahoomail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <20000202010550.16864.qmail@web112.yahoomail.com>; from scip7050@yahoo.com on Tue, Feb 01, 2000 at 05:05:50PM -0800
Sender: owner-freebsd-smp@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

* 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


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-smp" in the body of the message