[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lwip-users] Re: [lwip] pbuf_pool_alloc_lock
|
From: |
James Roth |
|
Subject: |
[lwip-users] Re: [lwip] pbuf_pool_alloc_lock |
|
Date: |
Wed, 08 Jan 2003 23:26:56 -0000 |
--------------030102090004020307000704
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Kieran Mansley wrote:
>On Wed, 6 Mar 2002, Mumtaz Ahmad wrote:
>
>>Hi
>>
>>whats the purpose of
>>pbuf_pool_alloc_lock and
>>pbuf_pool_alloc_free
>>
>>If these are to secure some critical areas in pbuf.c code then they must be
>>semaphores
>>
>
>They are there to control access to the list of pbufs - this list is
>changed in pbuf_pool_alloc() and pbuf_refresh(), but must only be changed
>by one at once.
>
>Semaphores (as implemented in sys_arch.c) would do the same job, but are a
>bit heavyweight for this application as they are really condition
>variables rather than just plain semaphores. This means you are able to
>block on a resource using them. Semaphores in their simplist case are
>just mutexes. (I'm not sure I'm explaining this very well - unfortunately
>the terms "condition variable", "semaphore" and "mutex" aren't always used
>properly or defined rigourously, so it can be confusing!)
>
>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?
>
>
>
>[This message was sent through the lwip discussion list.]
>
--
James Roth <address@hidden>
Shugyo Design Technologies
http://www.shugyodesign.com/
--------------030102090004020307000704
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<html>
<head>
</head>
<body>
Kieran Mansley wrote:<br>
<blockquote type="cite" cite="mid:address@hidden">
<pre wrap="">On Wed, 6 Mar 2002, Mumtaz Ahmad wrote:<br><br></pre>
<blockquote type="cite">
<pre wrap="">Hi<br><br>whats the purpose of<br>pbuf_pool_alloc_lock
and<br>pbuf_pool_alloc_free<br><br>If these are to secure some critical areas
in pbuf.c code then they must be<br>semaphores<br></pre>
</blockquote>
<pre wrap=""><!----><br>They are there to control access to the list of
pbufs - this list is<br>changed in pbuf_pool_alloc() and pbuf_refresh(), but
must only be changed<br>by one at once.<br><br>Semaphores (as implemented in
sys_arch.c) would do the same job, but are a<br>bit heavyweight for this
application as they are really condition<br>variables rather than just plain
semaphores. This means you are able to<br>block on a resource using them.
Semaphores in their simplist case are<br>just mutexes. (I'm not sure I'm
explaining this very well - unfortunately<br>the terms "condition variable",
"semaphore" and "mutex" aren't always used<br>properly or defined rigourously,
so it can be confusing!)<br><br>So, the reason (I think) they're not semaphores
is the pbuf code never<br>blocks on one of these resources - if it is unable to
to obtain one of the<br>locks it simply returns that it couldn't allocate the
memory. Memory<br>allocation routines need to be fast!<br><br></p
re>
</blockquote>
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.<br>
<br>
Does anyone else see this? Maybe there are semaphores
guarding this
at some other level?<br>
<blockquote type="cite" cite="mid:address@hidden">
<pre wrap=""><br><br><br>[This message was sent through the lwip
discussion list.]<br></pre>
</blockquote>
<br>
<pre class="moz-signature" cols="$mailwrapcol">--
James Roth <a class="moz-txt-link-rfc2396E"
href="mailto:address@hidden";><address@hidden></a>
Shugyo Design Technologies
<a class="moz-txt-link-freetext"
href="http://www.shugyodesign.com/";>http://www.shugyodesign.com/</a>
</pre>
<br>
</body>
</html>
--------------030102090004020307000704--
[This message was sent through the lwip discussion list.]
- [lwip-users] Re: [lwip] pbuf_pool_alloc_lock,
James Roth <=