RE: [lwip-users] performance in sending / receiving

[Goldschmidt Simon]

Hi Robert,


> right now I have the threads structured like this (highest to lowest
> priority):
> 
> - highest priority is the thread for the HW interface, it 
> takes lwip's packets from a queue and passes them to the HW 
> (or reads them from the HW and passes them to lwip...)
> - the next thread is the timer thread, which only calls 
> tcp_tmr and etharp_tmr periodically
> - then there's lwip's tcp/ip thread
> - and the lowest thread is the application doing the the 
> send/recv calls.

The threads look good to me except for one thing:
As far as I know, you must not call the timers from a different thread.
The simple reason for that is that if calling from another thread (which
has a higher prio than the tcpip-thread), the timer can interrupt e.g.
tcp processing and call the same function twice, resulting in corruption
of global variables. For arp it's nearly the same (arp table gets
modified). Lwip is not protected against multiple threads running in the
stack's context at the same time.

Instead, the timers should be called every time the tcpip-thread waits
for a semaphore, in which case it is not in any stack-function and the
timer functions can safely be called. This is the way Thomas described
it in his last post.

> Is there anything like a suggested model for those thread priorities?

None that I know of, but you got it right, I think. I have it exactly
the way you have and it's working fine. You shouldn't give your
application thread a higher prio than the stack, though. This would
block e.g. tcpip timers from running correctly if your application does
a lot of other things while not using sockets.


Simon.