Date: Thu, 21 Dec 2000 10:34:23 -0800 From: Julian Elischer <julian@elischer.org> To: smp@freebsd.org Cc: archie@freebsd.org Subject: looking for locking advice.. Message-ID: <3A424D2F.6524EC06@elischer.org>
index | next in thread | raw e-mail
As I'm sure everyone is aware.. I'm going through the exercise of 'locking down'
Netgraph. it requires some changes to teh way netgraph doens things but the
basic work has proved interesting and not too onerous. owever I still have one
part of teh system that needs work and I'm looking for advice or samlples of how
people locked down similar modules (if anyone has tackled such a module yet)..
it's the global netgraph data structures.. basically a hash table of exisiting
nodes by node-ID nad another by 'name'. In addition, there is a list of loaded
netgraph modules.
This doesn't sound too difficult, and I know I can lock it down if I use heavy
enough locking..
what I want advice on though is how to do it relatively efficiently.
Whenever a netgraph node sends a message to another node, it has several
alternatives.
Firstly, if they are directyl connected, it can pass it directly.
Secondly if it is indirectly conected, it can pass it via a 'source routed' form
of address, however there is a strong possibility that this mechanism may be
removed from netgraph as it
hasn't proved THAT useful. I'm still thinking about it..
The third methid is to give the globally uniqur netgraph node ID for the
recipient node, or it's alocated name. This requires that I do a hash-lookup.
These could be quite frequent, and theoretically there is no reason why several
might not be done at once in an SMP environment. However addition or deletion of
a node of course requires that all lookups stop until the changes have been
made. This implies possibly a reader-writer lock (again).
Alterantively I could use a simple mutex, and serialise lookups. Either way, I
need to
handle the case where an interrupt occurs and decides to do an operation which
cannot proceed because the interrupted process holds the lock (pretty basic
stuff really). The current mutex code seems to block interrupts for the entire
period that the mutex is held. This seems a bit draconian. Alternate operations
woudl be to allow the intrrupt thread to sleep and continue the interrrupted
operation until the lock is released at which time the interrupt thread can
continue.
My questions are:
Do we yet support full sleeping by interrupt threads? And if so, what is the
general
thought on this? How do we ensure that the interrupt thread is sheduled REALLY
SOON
after the lock is released. Is it preferable to sleep an interrupt thread
instead of blocking the interrupts and stopping it from happenning in the first
place? Is there a good way to tell that the caller is in an interrupt context?
Pointers to appropriate examples of people handling these problems would be
greatly appreciated. I have already looked at quite a lot of code but if anyone
has an example of which they are really proud, I'd love to see it.
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
home |
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3A424D2F.6524EC06>