Regarding if_alloc()

[Robert Watson]

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