The lwIP core isn't thread safe. If we have to use lwIP in a multithread environment, we should (or HAVE TO) use "upper" API layers (netconn or sockets). When using raw API you need to protect yourself and the core.
- Sockets generally can't be used by more than one application thread (on udp/raw netconn, doing a sendto/recv is currently possible).
- Concurrent calls on some upper operations have to be handled directly by the application: socket, bind, connect, setsockopt and close. It's the lwIP role to handle that (for example, it will be difficult to know if an "int socket" is always same between close/socket calls:
Task1
int s1=socket() (tell s1=5)
Task1,Task2
use s1 with send,recv (ok, it could be possible).
Task2
closesocket(s1)
Task3
int s2=socket() (and... it could be s2=5)
Task1
send(s1) !!!! Problem, s1 would not the same proto/port than the first we open,
!!!! but only application can know that !!!!
- Some operations could be changed to be thread-safe: recv, recvfrom, send, sendto... To enable fullduplex protocols. We have to move some processing from netconn/sockets to api_msg, but it's possible, and can even be faster... But it's not yet possible.
Some others information to remember:
- Some special functions can also cause problems regarding multithreading: netif_xxx and dhcp_xxx. These functions use the same variables as tcpip_thread.
Other examples
- If an "application" thread removes a netif while tcpip_thread is running, this may result in a crash. Adding two netif at the same time can result in a missing interface (https://savannah.nongnu.org/bugs/?19347).
- If an "application" thread stops dhcp on an interface, because the netif's dhcp field can be used by dhcp's timers (runnning in tcpip_thread context), you can get a crash (https://savannah.nongnu.org/patch/?5798).
To avoid the previous 2 problems, you could use "netifapi" which is very close to "netif" and "dhcp" API.