Date: Tue, 05 Dec 2000 05:11:55 -0800 From: Julian Elischer <julian@elischer.org> To: Mike Smith <msmith@freebsd.org> Cc: brian@freebsd.org, archie@freebsd.org, phk@freebsd.org, smp@freebsd.org Subject: Re: Netgraph and SMP Message-ID: <3A2CE99B.CBD857CD@elischer.org> References: <200012042140.eB4Le9F01294@mass.osd.bsdi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Mike Smith wrote:
>
> 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'd agree with this as long as getting and releasing READ mode locks
is very fast in the standard case. You are right. Setup times are
really quite irrelevent unless of course you want to have completely
uninterrupted flow in one part of the graph while you change something
elsewhere in the graph. But I think even that would be acceptable if
coded right..
One possibility I was thinking about was to break the overall system
into 'graphs'. A very busy heavily networked system might have several
disjoint graphs. There would be no point in locking a graph you were
not going to alter.
I'm going to check out the locks available to see what I can use.
>
> > 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
--
__--_|\ 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3A2CE99B.CBD857CD>