Re: [lwip-users] Socket API thread safe?

[Leon Woestenberg]

Hello Peter,

On Fri, 2004-06-11 at 12:55, Peter Graf wrote:
> >>Leon Woestenberg wrote:
> >>>This is a recurring topic (and rightly so).
> >>>lwIP socket API is *not* multi-threaded safe in the *generic* sense, 
> >>>i.e. for a full-pre-emptive environment (this is as far as I know).
> >>So how do you know (given a proper implementation of sysarch and 
> >>lightweight prot. of course)? Can you provide an example?
> >I do not know for certain, but lets take an example where I think it
> >goes wrong:
> >
> >1 - network interface hardware receives packet, raises interrupt
> >2 - the lwIP netif device driver's foobar_input() funtion is called
> >     from a task that is made runnable, triggered by the interrupt.
> >3 - the packet happens to update the ARP table
> >4 - During 3, a higher priority task becomes runnable (and thus running)
> >and sends out a packet on its own private UDP socket.
> >
> >We have a concurrent reader and writer in the ARP module and have
> >incorrect behaviour.
> 
> Thanks. I think you are right. Now it becomes clearer that I never saw an 
> effect like this, because in my case:
> 
Yes, I assumed you are in a fully pre-emptive environment but like I
said in one of my first sentences (see above):

>>>lwIP socket API is *not* multi-threaded safe in the *generic* sense, 

i.e. there are some critical sections in the code that can clash, and
mostly so when concurrent in/out traffic walks through the stack. This
can currently only simply be protected against using a big lock approach
where you regard the lwIP stack as one big resource.

> a. The task that is triggered by the interrupt has highest possible priority
> b. I have little movement in the ARP table. There are few local hosts, most 
> traffic goes to the gateway.
> c. I use TCP rather than UDP
> 
> Can we say that the essential thread-safety problems are restricted to ARP? 
>
This needs investigation. We need to walk through all possible traces of
where a pbuf travels and see wherever we modify a shared resource. Yes,
ARP comes to mind for sure, but I suspect there are nitty tiny spots
elsewhere. This is exactly why I have repeated that lwIP is not
considered fully multi-threaded safe.

> To me it looks like (almost) the only case where the sequential API is 
> circumvented.
> 
True. Someone might be willing to fix this, but the hard thing is that
you do not want to have recursive locking of mutexes. 

> experience anyway - I can not prove correctness. I have, however, used lwIP 
> quite a lot, and at found it stable enought to be _useful_ in a 
> full-pre-emptive environment.
> 
Depending on how your set of tasks pre-empt each other, you might be on
the safe side (maybe even fully thread safe in your case). Also, no
proof there.

Thanks for your input!

Leon.