lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-users] Mailboxes and Semaphores


From: address@hidden
Subject: Re: [lwip-users] Mailboxes and Semaphores
Date: Sat, 11 Apr 2009 15:38:56 +0200
User-agent: Thunderbird 2.0.0.21 (Macintosh/20090302)

If I remember correctly, there are many places in the stack where your simple semaphore can be used (tcpip_thread, netconn semaphores, etc.) but there are also other usages where multiple waiting threads have to be supported (i.e. locking the heap in mem_malloc). So I guess you are right that the generic sys_sem_t must be the multiple-type.

Speaking of deallocation: I also ran lwIP on an OS which didn't support this. I ended up in having a preallocated list/array of mboxes/semaphores and returning an instance of that list in sys_sem_new().

Simon


Timmy Brolin wrote:
Hello,
I have A few questions about LwIP OS requirements..

Our operating system provides two kinds of semaphores. The normal (and
resource-light) semaphore only allows a single task to block on it at
any one time. There is also a second type which allows multiple tasks to
block on it at the same time, but it requires a bit more memory resources.
Am I correct in assuming that LwIP requires multiple tasks to block on
the same semaphore? Are there any semaphores in LwIP which could do with
the simpler semaphore type?

The mailbox system in our operating system is based on the standard
semaphores, so only one task may block on a mailbox at any one time. Is
this acceptable for LwIP?

Our OS has a limitation in that semaphores and mailboxes never can be
deallocated, and I was hoping that the addition of a deallocation
funtion for semaphores and mailboxes would be enough to get LwIP running
on our system. I would prefer not having to write a new mailbox system
as well.. :-)

Regards,
Timmy Brolin


_______________________________________________
lwip-users mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/lwip-users






reply via email to

[Prev in Thread] Current Thread [Next in Thread]