Re: [lwip-users] Do functions like sys_mbox_invalid() need to be thread safe?

[Grant Edwards]

On 2021-11-10, goldsimon@gmx.de <goldsimon@gmx.de> wrote:

> Am 10.11.2021 um 20:43 schrieb Grant Edwards:

>> I'm workikng on a port done by somebody else, and they seem to have
>> assumed that functions like sys_mbox_set_invalid() don't need to be
>> thread-safe.  But, they did add mutexes to make sure that some
>> other functions like like sys_mbox_free() and _new() are
>> thread-safe.
>
> Thread-safe related to what? Globally (all mboxes) or local to the mbox?

Globally (mostly), and globally doesn't mean just objects of the same
type. On my platform, there could be race conditions between mutex
and semaphore functions. I'm not concerned about race conditions among
signal/wait/lock/unlock functions. It's generally new/free/set_invalid
that can cause problems.

> I don't think thread-safety is required. It should just work. If you
> need guidance, take a look at our FreeRTOS port, which should work
> (without additional thread-safety):
>
> https://git.savannah.nongnu.org/cgit/lwip.git/tree/contrib/ports/freertos/sys_arch.c

Thanks, I'll use that as a model, but FreeRTOS is different enough
from my RTOS that it doesn't answer some questions.

>> The documentation I've found at https://www.nongnu.org/lwip/2_1_x/
>> seems to be mute on that subject.
>>
>> Do the varios sys_* functions for mutex, semaphore, mailbox functions
>> in the "OS abstraction layer" need to be thread safe?
>>
>> Or are they only called under some sort of mutex/protection?
>
> I'm still not sure which specific thread-safety you mean:

I mean can two invocations of the sys_* (mailbox, mutex or semaphore)
functions happen "at the same time".  For example: can the execution
of one call to sys_{sem,mutex,mbox}_set_invalid() be interrupted or
suspended by another call to that same function? [The second
invocation would be for a different object obviously.] After the second
invocation finished, the first one would then resume.

If that can happen, I need to add code to make sure certain sections
of those functions execute atomically.

> - allocation is per definition thread-safe since noone knows the object
>   at that state

That depends on how allocation is implemented. If mailboxes,
semaphores, and mutexes are allocated from a fixed pool of eternal,
pre-existing objects, and allocations or deallocations can happen "in
parallel" with each other, then the pool state needs to be protected
by a mutex.

"In parallel" includes single-core threaded systems where a context
switch could occur in the middle of one of those calls and the new
context could call that same function or a different, related
function.

> - using the mbox/semaphore is normally thread-safe because you normally
>   just pass on some variables to OS core functions

There is enough of an "impedance mismatch" between lwIP and my RTOS
that I can't "just pass some variables to OS core functions".

> - deallocation is only done when the stack knows the object is not used
>   any more

But can a call to deallocate an object be executed in parallel with a
call to allocate or deallocate for a different object?

> Noone before you has expressed a need for documentation on this
> topic, so no, it's not documented yet.

The authors of the port I'm working on clearly needed documentation on
this topic. :)

If thread safety isn't needed, then they've put mutexes in where they
didn't need to. If thread safety _is_ needed, then I've got race
conditions that could cause problems.

Thanks,

--
Grant