[riot-notifications] [RIOT-OS/RIOT] core: Added thread_signal & thread_await_signal (#11069)

Kaspar Schleiser notifications at github.com
Wed Mar 13 11:28:59 CET 2019


>     1. This is clearly shown by the fact that other developers resort to using `thread_flags` instead when it is an overkill.

I think there is a misunderstanding. Thread flags are not overkill compared to mutexes. E.g., in this minimal example:

```
#ifdef MODULE_CORE_THREAD_FLAGS
#include "thread_flags.h"
#else
#include "mutex.h"
#endif

int main(void)
{
#ifdef MODULE_CORE_THREAD_FLAGS
    thread_flags_set((thread_t *)sched_active_thread, 0x1);
    thread_flags_wait_any(0x01);
#else
    mutex_t m;
    mutex_unlock(&m);
    mutex_lock(&m);
#endif
    return 0;
}
```

When compiled for samr21-xpro, the thread thread flags version uses 80b more code, which I'd hardly call overkill.

The change you made to kw2xrf suggests otherwise, but I think the mechanics that were using thread-flags were overly complicated to begin with.

With mutexes as used in this PR, the semantics are "thread_await_signal(signal) only returns if signal has been set at least once since the last call".

With thread_flags they are "thread_flags_await_any(foo) only returns if the flag has been set at least once since last call (to thread_flags_set(thread))". That's basically the same.

So the code size / RAM argument is off. We'd need to compare the same logic. At that point, (apart from the 80 bytes), it boils down to what the rest of the system is using.

> makes the code more readable

This is pretty subjective ;)

Please don't get me wrong, I want this included. This PR wraps a common lock pattern into its own API. That is a good thing, as this pattern doesn't seem well known enough.
I'm trying to get it conceptually right so we'll not cause new confusion.

> I don't have strong feelings about the name and happily change it

- being an IPC mechanism, I don't think it belongs into ```thread.[hc]```
- calling it ```thread_signal_*()``` makes it seem like it operates on a thread, which it doesn't (really), as any thread could wait for the signal object
- in that case, only one thread (the one with the highest priority) will be woken up, which might be unexpected

Unfortunately I don't have a much better name. 
flag_t, flag_init(), flag_wake_one(), flag_wait() come to mind.

Or am I bikeshedding too much?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/RIOT-OS/RIOT/pull/11069#issuecomment-472365799
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riot-os.org/pipermail/notifications/attachments/20190313/5a85a678/attachment.html>


More information about the notifications mailing list