Am 30.12.2022 um 20:36 schrieb Christoph M. Wintersteiger:
I’m getting some mixed signals about core locking and I wonder whether
someone could clarify this. The documentation for
LWIP_ASSERT_CORE_LOCKED
(https://www.nongnu.org/lwip/2_1_x/group__lwip__opts__lock.html#ga6a30040db307b3459fc11906bd433f75
<https://www.nongnu.org/lwip/2_1_x/group__lwip__opts__lock.html#ga6a30040db307b3459fc11906bd433f75>
) says:
Not in ISR (this should be checked for NO_SYS==1, too!)
From this I infer that core locking with NO_SYS==1 is possible and
indeed a good idea.
However, when I enable core locking (#define LWIP_TCPIP_CORE_LOCKING 1),
the LOCK_TCPIP_CORE macro is undefined. I figured I’ll just lock it
myself via sys_mutex_lock(&lock_tcpip_core), but it appears that
sys_mutex_lock is defined to do nothing at all (sys.h, #if NO_SYS).
So, has support for core locking + NO_SYS been removed, and the
documentation is lagging behind, or is there a different way to enable this?
(Context: I’m using MQTT and it appears that it has a hard requirement
for core locking…)
No, core locking for NO_SYS==1 has not yet been implemented in a
portable way (because we do not have portability defines for executiong
contexts in that case). The comment simply wants to say that it would be
a good idea to do so.
But you can implement the macros on your own. You could, for example,
implement it by using an atomic instruction to set and/or check which
execution context is active in lwip.
Using that, you could then e.g. mark the main loop being active in lwIP.
Now when an interrupt tries core-locking, it would fail (since by
design, it cannot wait for the main-loop to release the lock).
Regards,
Simon
_______________________________________________
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
