Re: [lwip-users] Core locking with NO_SYS

[address@hidden]

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