From owner-freebsd-smp  Wed Jul 16 15:12:08 1997
Return-Path: <owner-smp>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id PAA12716
          for smp-outgoing; Wed, 16 Jul 1997 15:12:08 -0700 (PDT)
Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50])
          by hub.freebsd.org (8.8.5/8.8.5) with SMTP id PAA12683;
          Wed, 16 Jul 1997 15:11:59 -0700 (PDT)
Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id PAA01775; Wed, 16 Jul 1997 15:10:58 -0700
From: Terry Lambert <terry@lambert.org>
Message-Id: <199707162210.PAA01775@phaeton.artisoft.com>
Subject: Re: pushdown of "giant lock"
To: smp@csn.net (Steve Passe)
Date: Wed, 16 Jul 1997 15:10:57 -0700 (MST)
Cc: terry@lambert.org, smp@FreeBSD.ORG, peter@spinner.dialix.com.au,
        dyson@FreeBSD.ORG
In-Reply-To: <199707162159.PAA10171@Ilsa.StevesCafe.com> from "Steve Passe" at Jul 16, 97 03:59:26 pm
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-smp@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> > The ONLY issue I have with this proposed implementation is "what
> > happens if...":
> > 
> > 	A)	getSYS_mplock
> > 	B)	getTRAP_mplock
> > 	A)	getTRAP_mplock	<< BLOCK
> > 	B)	getSYS_mplock	<< DEADLOCK
> 
> this wont happen as B would block on getTRAP_mplock (A holds GL).  so the
> following A wont block, no deadlock.  this assummes the 1st step, ie both
> SYS & TRAP continue to use the GL.
> 
> When we take the next step and make SYS/TRAP MP-safe we may need to make them
> completely MP-safe in one step to avoid some deadlock issues...

Yes, this is the occasion I meant; using one lock from three macros
is not a very interesting case.  ;-).


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.