|Subject:||Re: [lwip-users] critical section protection + timer issues questions|
|Date:||Thu, 17 Feb 2005 15:41:02 -0800|
|User-agent:||Mozilla Thunderbird 1.0 (Windows/20041206)|
Please see below|
Scott Taggart wrote:
I can't really speak about the raw interface. I've only worked in situations where the higher level interfaces were used and TCP/IP was running in its own thread. For the most part, the fact that TCP/IP runs in its own thread provides the needed protections.
Even in this case, though, there are some worries. I would urge you to use SYS_LIGHTWEIGHT_PROT, for example, since I don't believe that any other option provides adequate protection to the PBUF pool. I would also advise you to avoid trying to use the same socket in two different threads, e.g., pending on a read of the socket in one thread while writing to it in another.
You should also watch out for the way that etharp gets called. etharp_ip_output tends to get called in the context of the TCP/IP task, while etharp_arp_input is often called from an ethernet receive task. Depending on how you implement it, the arp timer may end up firing in yet another task. This has the potential to cause problems, since the arp list doesn't have mutex protection. In this instance, it is fairly easy to add your own protections, since the etharp calls are going to be in code that you are adding, anyway.
You've got this right. The timer mechansim rests on the sys.c wrappers for your OS's semaphore and mailbox mechanisms. When you call sys_timeout, the timeout is created in the list associated with the current task. That task needs to pend on a sys_sem, a sys_mbox, or sys_mssleep. The timeout function ends up getting called in the context of that same task, and things work out. If this is the timeout mechanism that you need, you're all set. If you need something different, you're on your own.
As an example, consider the tcp timer. The tcp/ip task gets launched by tcpip_init. After the tcp/ip task has gotten itself initialized, it invokes a callback function to let the caller of tcpip_init know that the operation is completed. The callback function is executing in the tcp/ip task context. That's a perfect place to make the initial sys_timeout call to start the tcp timer. The tcp/ip thread does use the sys stuff, so the timer will fire. And when it does fire, the tcp timer will be running in the context of the tcp/ip thread, thus precluding any potential conflicts as it processes through the PCBs.
The tcp timer illustrates the benefits of the approach implemented in sys.c. When you use a timer, it can be important to control the task context in which the timer code executes. If you can get it to run in the right task, then you can often avoid resource conflicts without explicitly using mutexes.
|[Prev in Thread]||Current Thread||[Next in Thread]|