lwIP Wiki

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:
  int s1=socket() (tell s1=5)
  use s1 with send,recv (ok, it could be possible).
  int s2=socket() (and... it could be s2=5)
  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.