[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
Re: [lwip-users] How to use LWIP from FreeRTOS tasks - a thread safety question
Tue, 12 Jul 2022 08:01:55 -0400
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
Has this ever worked, or for 2 years it always crashed if you used
What exactly "crashes the whole thing"?
You're aware of the numerous issues surrounding STM-provided
Hope this helps,
Best Regards, Dave
On 7/12/2022 5:32 AM, Peter wrote:
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
unrelated to LWIP_TCPIP_CORE_LOCKING.
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, email@example.com, Skype