[lwip-users] Re: [lwip] pbuf_pool_alloc_lock

[Adam Dunkels]

Hi James, Kieran and Mumtaz!

On Wednesday 13 March 2002 22.48, you wrote:
> >So, the reason (I think) they're not semaphores is the pbuf code never
> >blocks on one of these resources - if it is unable to to obtain one of the
> >locks it simply returns that it couldn't allocate the memory.  Memory
> >allocation routines need to be fast!
>
>     The operations on the *_lock variables (which are u8_t) are far from
> atomic on many processors.  With a multithreaded system, this could
> result in unpredictable happenings.  For instance, var++ can result in a
> load, increment, and store.  Two threads doing this "at the same time"
> can result in var++ adding 1 to var OR adding 2 to var.  So, with the
> var-- operation, the lock may stay locked forever.  This would not a
> problem for stand-alone lwIP users.
>
>     Does anyone else see this?  Maybe there are semaphores guarding this
> at some other level?

In fact, it doesn't matter if the ++ operation is atomic because that is only 
done in one thread at a time. The pbuf_pool_alloc_lock is incremented and 
decremented only in the device driver (we assume that all device drivers run 
in the same thread or are otherwise locked from eachother). All other threads 
use the pbuf_refresh() function which doesn't alter the pbuf_pool_alloc_lock, 
only checks it to see if it is safe to enter the section. Because this 
function is protected by a semaphore, only one thread runs it at a time. The 
pbuf_pool_free_lock is used to block any allocators (device drivers) that 
would happen to be interleaved into the pbuf_refresh() function.

That is how it is supposed to work, anyhow. Is there a flaw anywhere that I 
have overlooked?

Instead of the ++ and --, we could just use = 1 and = 0 instead. That would 
even make the code faster, and being easier to read as well.

/adam
-- 
Adam Dunkels <address@hidden>
http://www.sics.se/~adam
[This message was sent through the lwip discussion list.]