[Top][All Lists]

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

Re: [lwip-users] How to use LWIP from FreeRTOS tasks - a thread safety q

From: Dave Nadler
Subject: Re: [lwip-users] How to use LWIP from FreeRTOS tasks - a thread safety question
Date: Tue, 12 Jul 2022 08:01:55 -0400
User-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0

Hi Peter - Can you start at the beginning?
Has this ever worked, or for 2 years it always crashed if you used LWIP?
What exactly "crashes the whole thing"?
You're aware of the numerous issues surrounding STM-provided Ethernet driver?
Hope this helps,
Best Regards, Dave

On 7/12/2022 5:32 AM, Peter wrote:
Hi All,

I am new here. I've been working on a ARM32 32F417 project for a
couple of years. Someone else, working 1 day a week, implemented
FreeRTOS, LWIP and MbedTLS and I am now revisiting these issues which
I don't think were looked at in detail originally.

Specifically I would like to know what LWIP settings are needed to
achieve thread safety.

For example I have one thread doing NTP (socket() call to get a UDP
socket) and another thread doing a simple HTTP server (using the
netconn API which seems to end up in the same "socket" API as the

Reading the vast number of mostly inconclusive posts on the internet,
there appear to be two classes of API functions, and thread safety is
more easily achieved if you restrict yourself to just one of these
classes. But the advice is ambiguous.

It looks like the implementer is required to provide a mutex set/reset
function, although the need for this depends on which of the two above
API sections one is using. I also appears that if you use just one
class, the mutex is not necessary and just using the "critical
section" macros (which basically just disable interrupts) is

OTOH a lot of online text says that LWIP is thread safe "out of the
box" in some cases...

I am using Cube IDE and have been stepping through the code but I am
not much wiser.


The idea appears to have 

but that crashes the whole thing, presumably because nobody has
implemented any of the above mentioned hooks.

FreeRTOS can supply mutexes and these work very well. I use them all
over the place.

Looks like you have to implement these functions

#define LWIP_MEM_FREE_PROTECT()  sys_mutex_lock(&mem_mutex)
#define LWIP_MEM_FREE_UNPROTECT() sys_mutex_unlock(&mem_mutex)

There are what appear to be example functions in sys_arch.c under

I find all this very confusing because e.g. here
it states that

In OS mode, Callback-style APIs AND Sequential-style APIs can be used.
Sequential-style APIs are designed to be called from threads other
than the TCPIP thread, so there is nothing to consider here. The
implication is that these do not need mutex protection. And indeed
stepping through code such as

fd = socket(AF_INET, SOCK_DGRAM, 0);

does find that a mutex is used, deep down.

it calls conn = (struct netconn *)memp_malloc(MEMP_NETCONN);

which does SYS_ARCH_PROTECT(old_level);
but I can't see that defined anywhere so that is probably what needs
to be done if you are setting


What I can't find anywhere is whether the "sequential" functions are
thread-safe with or without LWIP_TCPIP_CORE_LOCKING.

And where does SYS_ARCH_PROTECT come into all this, since it seems

There is also a subtle issue which I am sure is unrelated to thread
safety whereby if a single UDP socket is opened, it causes the HTTP
server to be unable to transmit packets (lots of LWIP error
counters++) when TLS is doing to crypto handshake (2-3 secs). This
happens on the mere allocation of the UDP socket; no data being sent.
Debugging this is too complicated because nobody I know knows where to
look. It makes no difference what values one puts in the lwipopts.h
file. I could post the file here but it would make a long post amd
those tend to not produce replies :)

Thank you in advance for any help.


lwip-users mailing list

Dave Nadler, USA East Coast voice (978) 263-0097, drn@nadler.com, Skype 

reply via email to

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