From owner-freebsd-smp Mon Dec 4 13:31:22 2000 From owner-freebsd-smp@FreeBSD.ORG Mon Dec 4 13:31:20 2000 Return-Path: Delivered-To: freebsd-smp@freebsd.org Received: from mass.osd.bsdi.com (adsl-63-202-176-64.dsl.snfc21.pacbell.net [63.202.176.64]) by hub.freebsd.org (Postfix) with ESMTP id 6E53A37B400; Mon, 4 Dec 2000 13:31:19 -0800 (PST) Received: from mass.osd.bsdi.com (localhost [127.0.0.1]) by mass.osd.bsdi.com (8.11.0/8.11.1) with ESMTP id eB4Le9F01294; Mon, 4 Dec 2000 13:40:14 -0800 (PST) (envelope-from msmith@mass.osd.bsdi.com) Message-Id: <200012042140.eB4Le9F01294@mass.osd.bsdi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Julian Elischer Cc: brian@freebsd.org, archie@freebsd.org, phk@freebsd.org, smp@freebsd.org Subject: Re: Netgraph and SMP In-reply-to: Your message of "Sun, 03 Dec 2000 06:55:32 PST." <3A2A5EE3.56E711B8@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 04 Dec 2000 13:40:08 -0800 From: Mike Smith Sender: msmith@mass.osd.bsdi.com Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The simplest structure for this is a shared/exclusive lock that supports intention; Terry would have ranted about this. (He would have called it a SIX-lock, I think). In this model, you acquire the lock in 'shared' mode every time you enter Netgraph, and release it when you leave. When you plan to make changes to Netgraph, you get the lock in 'exclusive' mode. 'Intention' comes in here; now that you are trying to get the lock in exclusive mode, your intention is recorded and nobody else can get it in 'shared' mode, so eventually all the users drain out of Netgraph and you get the lock. This may sound simplistic, but given that you don't necessarily make changes to Netgraph very often, this is quite likely more than adequate for now. > I'm trying to figure out the locking needed for SMP in Netgraph. > > Here are some of the various constraints that I see. (some of theme are not just > SMP issues). > > 1/ can't remove modules that are being used (the base framework) or have living > nodes (other netgraph modules). > 2/ Cannot remove a node if it is in use, (or in a return stack somewhere) > 3/ Cannot unlink an 'edge' if someone is passing data across it. > 4/ cannot use edges and nodes that are in the process of being set up or torn > down. > 5/ Defered deliveries cannot be made to nodes that are being removed. > 6/ Nodes cannot be completely removed if there are pending deliveries for them. > > What locking schemes to otther people use for protecting intricate structures of > objects with various interconnections? The buffer cache is one example that > comes to mind, as is the routing table. > > Julian > -- > __--_|\ Julian Elischer > / \ julian@elischer.org > ( OZ ) World tour 2000 > ---> X_.---._/ presently in: Budapest > v > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-smp" in the body of the message > -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message