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.