On 2021-11-10, goldsi...@gmx.de <goldsi...@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 _______________________________________________ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
