[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Peter Graf
Subject: Re: [lwip-users] Socket API thread safe?
Date: Fri, 11 Jun 2004 12:56:53 +0200

Hi Leon,

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:

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? To me it looks like (almost) the only case where the sequential API is circumvented.

I have explicitly not mentioned a API here. I am just curious if this
case is covered. I am SURE the raw API is non-thread-safe, I just wish
to hear the netconn_ API is.

I can not say much about the netconn API, since I use the sockets layer on top, which provides further mutual exclusion. My view is just practical 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.

All the best

reply via email to

[Prev in Thread] Current Thread [Next in Thread]