demonstrator: take on shared event handler threads#12480
demonstrator: take on shared event handler threads#12480haukepetersen wants to merge 1 commit intoRIOT-OS:masterfrom
Conversation
|
Forgot: the discussion takes place in #12459, so please comment there. |
|
|
||
| /* syntactic sugar: we could give some names - however, we need to find a better | ||
| * way to do this non statically depending on the actual selected modules... */ | ||
| #define TASKLET_LOWPRIO (1u) /* position in params array */ |
There was a problem hiding this comment.
You could do something like this:
#define TASKLET_PRIO_LOWEST (0U)
#ifdef MODULE_TASKLET_PRIO_LOW
#define TASKLET_PRIO_LOW (TASKLET_PRIO_LOWEST + 1)
#else
#define TASKLET_PRIO_LOW (TASKLET_PRIO_LOWEST)
#endif
#ifdef MODULE_TASKLET_PRIO_MEDIUM
#define TASKLET_PRIO_MEDIUM (TASKLET_PRIO_LOW + 1)
#else
#define TASKLET_PRIO_LOW (TASKLET_PRIO_LOW)
#endif
#ifdef MODULE_TASKLET_PRIO_HIGH
#define TASKLET_PRIO_HIGH (TASKLET_PRIO_MEDIUM + 1)
#else
#define TASKLET_PRIO_HIGH (TASKLET_PRIO_MEDIUM)
#endif
#ifdef MODULE_TASKLET_PRIO_HIGHEST
#define TASKLET_PRIO_HIGHEST (TASKLET_PRIO_HIGH + 1)
#else
#define TASKLET_PRIO_HIGHEST (TASKLET_PRIO_HIGH)
#endif
#define TASKLET_PRIO_NUMOF (TASKLET_PRIO_HIGHEST + 1)
One could argue that it is a bit confusing that the defines for all 5 priority levels are always defined. But I would say that this is actually an advantage, as I could decided later on that I do not need the divide in lowest and low without having to change all uses of TASKLET_PRIO_LOW to TASKLET_PRIO_LOWEST.
There was a problem hiding this comment.
As stated, please lets first focus on the overall concept before jumping into implementation details...
|
Just so nobody gets a wrong idea: defining static variables in a header file, as done in this brain dump code, is a pretty stupid think of course :-) |
|
I think having multiple queues for now is a good approach. Eventually everything could be represented with a couple of queues, but this gives as a lot of flexibility for now. So, this gives the developer the mechanism to adapt the OS depending of the real time requirements. |
|
Thats probably the direction to go. Closing this in favor of #12474, so lets see about the implementation specifics there. |
Contribution description
Quickly drafted out my own ideas about the topic discussed in #12459. This is not meant to be ever merged, its rather to demonstrate some thoughts and contribute to the discussion pointed out above!
I wanted to try out, how the use of the term
taskletwould feel like when just just to provided the shared event handler threads (as proposed in #12474). If the discussion in the end just boils down to the name of the submodule, I couldn't care less. But the main things to take are IMHO:event_x()API call directly (in this case one array lookup)eventprovides -> timer handling ('event/timeout'), canceling events, ...Testing procedure
never to be tested :-)
Issues/PRs references
#12459 and #12474