Date: Mon, 04 Dec 2000 13:40:08 -0800 From: Mike Smith <msmith@freebsd.org> To: Julian Elischer <julian@elischer.org> Cc: brian@freebsd.org, archie@freebsd.org, phk@freebsd.org, smp@freebsd.org Subject: Re: Netgraph and SMP Message-ID: <200012042140.eB4Le9F01294@mass.osd.bsdi.com> In-Reply-To: Your message of "Sun, 03 Dec 2000 06:55:32 PST." <3A2A5EE3.56E711B8@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200012042140.eB4Le9F01294>