[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lwip-users] Do functions like sys_mbox_invalid() need to be thread
From: |
address@hidden |
Subject: |
Re: [lwip-users] Do functions like sys_mbox_invalid() need to be thread safe? |
Date: |
Wed, 10 Nov 2021 21:20:09 +0100 |
User-agent: |
Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 |
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?
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
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:
- allocation is per definition thread-safe since noone knows the object
at that state
- using the mbox/semaphore is normally thread-safe because you normally
just pass on some variables to OS core functions
- deallocation is only done when the stack knows the object is not used
any more
Is this documented somewhere I should have looked and didn't?
Noone before you has expressed a need for documentation on this topic,
so no, it's not documented yet.
Regards,
Simon