Re: [lwip-users] Do functions like sys_mbox_invalid() need to be thread safe?
Am 10.11.2021 um 22:34 schrieb Grant Edwards: [..] I don't quite understand: what does "points are safe" mean? I mean for one object, lock/unlock, post/fetch or signal/wait can be called by multiple threads simultaneously, but deallocation is ensured to be called from one thread only, when the object is otherwise unused. Regards, Simon ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Do functions like sys_mbox_invalid() need to be thread safe?
On 2021-11-10, goldsi...@gmx.de wrote:
>
>> 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.
>
> Yes, ok, that can of course happen.
I thought so. The original authors of the port clearly did not, even
though they seemed aware of the possiblity of some other functions
being called re-entrantly.
> There's no restriction between calling those functions on different
> objects.
OK, thanks — I've definitely got race conditions I need to fix. :)
> The only guarantee you get with lwIP is probably that allocation and
> deallocation points are safe...
I don't quite understand: what does "points are safe" mean?
Thanks again,
--
Grant
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Do functions like sys_mbox_invalid() need to be thread safe?
Am 10.11.2021 um 22:04 schrieb Grant Edwards:
On 2021-11-10, 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.
Yes, ok, that can of course happen. There's no restriction between
calling those functions on different objects. The only guarantee you get
with lwIP is probably that allocation and deallocation points are safe...
Regards,
Simon
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Do functions like sys_mbox_invalid() need to be thread safe?
On 2021-11-10, 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
Re: [lwip-users] Do functions like sys_mbox_invalid() need to be thread safe?
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 ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
[lwip-users] Do functions like sys_mbox_invalid() need to be thread safe?
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. 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? Is this documented somewhere I should have looked and didn't? -- Grant ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
