[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lwip-users] Re: [lwip] pbuf_pool_alloc_lock
From: |
Adam Dunkels |
Subject: |
[lwip-users] Re: [lwip] pbuf_pool_alloc_lock |
Date: |
Thu, 09 Jan 2003 00:27:41 -0000 |
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.]