From owner-freebsd-smp  Thu Dec  5 16:23:35 1996
Return-Path: <owner-smp>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.4/8.8.4) id QAA14486
          for smp-outgoing; Thu, 5 Dec 1996 16:23:35 -0800 (PST)
Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131])
          by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id QAA14480
          for <smp@freebsd.org>; Thu, 5 Dec 1996 16:23:31 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id RAA16023; Thu, 5 Dec 1996 17:21:32 -0700
Message-Id: <199612060021.RAA16023@clem.systemsix.com>
X-Authentication-Warning: clem.systemsix.com: Host localhost didn't use HELO protocol
X-Mailer: exmh version 1.6.5 12/11/95
From: Steve Passe <smp@csn.net>
To: Thomas Pfenning <thomaspf@microsoft.com>
cc: "'Chris Csanady'" <ccsanady@friley216.res.iastate.edu>,
        "'Peter Wemm'" <peter@spinner.dialix.com>,
        "'smp@freebsd.org'" <smp@freebsd.org>
Subject: Re: make locking more generic? 
In-reply-to: Your message of "Thu, 05 Dec 1996 10:55:33 PST."
             <c=US%a=_%p=msft%l=RED-81-MSG-961205185533Z-4388@INET-02-IMC.microsoft.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 05 Dec 1996 17:21:31 -0700
Sender: owner-smp@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

Hi,

> Doesn't the lock version in this mail actual trash the cached value for
> bootlock on every spin? What about using MCS queueing locks to solve
> both the cache trashing and the reentrance at the same time. 
 ...
> >>ENTRY(boot_lock)
> >>	/* This is the Intel reccomended semaphore method */
> >>	movb	$0xff, %al
> >>2:
> >>	xchgb	%al, bootlock		/* xchg is implicitly locked */
> >>	cmpb	$0xff, %al
> >>	jz	2b
> >>	ret
> >>
> >>ENTRY(boot_unlock)
> >>	movb	$0, %al
> >>	xchgb	%al, bootlock		/* xchg is implicitly locked */
> >>	ret
> >>
> >>	/* initial value is 0xff, or "busy" */
> >>	.globl	bootlock
> >>bootlock:	.byte 0xff

no,

 %al has 0xff in it,
 the initial locked value is 0xff
 each spin puts %al (ie 0xff) into bootlock and bootlock into %al
 so bootlock remains 0xff until the unlock function is called

 the unlock functiom puts 0x00 into %al, then does the xchgb, putting
 the 0x00 into bootlock, and tossing the contents of %al as it returns.

 so the next spin on the lock by ONE AP puts %al (0xff everytime) into
 bootlock, and gets %al filled with the 0x00 placed there by unlock.

 the other APs get the 0xff placed there by the one successful xchgb
 that the 1st AP made.

--
Steve Passe	| powered by
smp@csn.net	|            FreeBSD