On Tue, 22 Apr 2008, vijay singh wrote:
Robert, I am working on the patch, but I had a few questions. If we drop the
lock while if_grow() is running, how do we prevent a second caller, blocked
in if_alloc() to start scanning the ifindex_table, and end up deciding to
grow it again. In other words, we need to stall the ifindex_table scan in
if_alloc() till if_grow() has achieved finished. Since if_grow() will be
called relatively infrequently, should we consider holding the lock through
the routine? Your comments and suggestions are welcome.
Vijay,
if_grow() will be called only infrequently, but we do need to handle it
correctly. Usually code of this sort handles races in the following sort of
optimistic way:
LOCK();
while (need space) {
LOCK();
allocate new space;
UNLOCK();
if (new space > old space)
install new space, free old space;
else
free new space;
}
use space;
UNLOCK();
Basically, you need to gracefully handle the case where you released the lock,
allocated the space, re-acquired the lock, and discovered someone else had
done the same. The reason you need a while loop is that you may have rather
seriously lost the race -- someone else may have allocated space, and then
several someone elses may have then used the sapce, leaving you with less
memory than you need, but still needing to allocate yet more memory. The
above is not starvation free, but in practice the byindex table doesn't grow
all that much, and should never trigger the race anyway :-).
Robert N M Watson
Computer Laboratory
University of Cambridge
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
