Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 04 Dec 2000 22:31:36 +0000
From:      Brian Somers <brian@Awfulhak.org>
To:        Mike Smith <msmith@FreeBSD.org>
Cc:        Julian Elischer <julian@elischer.org>, brian@FreeBSD.org, archie@FreeBSD.org, phk@FreeBSD.org, smp@FreeBSD.org, brian@Awfulhak.org
Subject:   Re: Netgraph and SMP 
Message-ID:  <200012042231.eB4MVaD93192@hak.lan.Awfulhak.org>
In-Reply-To: Message from Mike Smith <msmith@FreeBSD.org>  of "Mon, 04 Dec 2000 13:40:08 PST." <200012042140.eB4Le9F01294@mass.osd.bsdi.com> 

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).
[.....]
> 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.

Nice, I never realised there were shared/exclusive locks available.  
I think netgraph nodes would also need to have a ``modevent'' that 
fails MOD_UNLOAD events if any locks are outstanding.

Of course there'll probably be loads of edge-cases :-/

> > 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

-- 
Brian <brian@Awfulhak.org>                        <brian@[uk.]FreeBSD.org>
      <http://www.Awfulhak.org>;                   <brian@[uk.]OpenBSD.org>
Don't _EVER_ lose your sense of humour !




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?200012042231.eB4MVaD93192>