sys/sched_rr: Add a round robin scheduler module

[kfessel]

I would like to use RIOT with multiple threads at the same priority,
that might not cooperate but should share CPU time. see #14810

Preconditions that influenced how this PR is written:

sys is not allowed to access core structures see #14810
core is not allowed to rely sys/xtimer see #15069
a core/timer is unlikely to come #15080

Contribution description

This:

• implements the timing part in a module in sys and

• adds an interface to core that provides information about the runqueues and the core round robin functionality.

• adds an thread duel example with multiple implementations for concurrent thread

How it works

This round robin scheduler, round robins the active priorities runqueue -that was what #14810 did- , if there is more than one thread.
It uses extra information to activate or inactivate -this was added with #15069-:

• It is inactivated if the last thread leaves a queue (it is not need anymore)
• It keeps hold of the queue it schedules even if a higher priority queue get active (most likely just for a short time).
• It gets activated if the active queue has more than 1 thread.
  (This implies: it may hold on a 1 thread runqueue and do a round robin, while this is an unnessecary call to the scheduler, that one is quiet effective in handling it (comparable to: yield_higher))

This is done to only have timer active if it is needed and to avoid stopping or restarting the timer which is processing the list of timers (O(n) with n = the number of active timers). While the example and test use only one timer -> O(n) for n=1 is quiet fast. real applications might have many more timers thus increase n.

Testing procedure

create multiple threads of same priority that should work in parallel
without this module only one of them will run.

or

use the example provided

enable and disable the round robin module and see how the threads work or not work in "parallel"

or

use the provided test sys_sched_round_robin which should run to [SUCESS] with sched_round_robin

(the main function locks itself by a mutex wich is relesed by a thread than runs parallel to an other thread)

the test can be tested by removing sched_round_robin from its USEMODULE than there will be no [SUCESS]

Issues/PRs references

#14810 #15069 #15080

@maribu @benpicco @fjmolinas might want to have a look at this

[fjmolinas]

seems there are a couple of unrelated commits..

[fjmolinas]

@kfessel the commit history seems a bit weird, the example is introduced before the functionality.

[kfessel]

the example before the feature can run without the feature and, since there is no round robin scheduling, not work. (at first i thought i go with one big commit and added the example first but than i saw the gitignore thing and went with mutiple commits)
the real history is i developed the most simple variant with #14810 than i improved to #15069 and now this is the features of #15069 without having *timer in core

[kfessel]

i squashed the fixups into three

[kfessel]

sorry for the huge number of fixups i did fix for the static tests but since i read the results while they where not finished complaining and in the next run they found new issues

I hope there are no static complains left (back to 5 fixups :( )

[maribu]

Some comments inline. Looks pretty good to me.

Would you mind to replace the evil_schedule_hack_dont_do_this_at_home() function in tests/malloc_thread_safety/main.c in an additional commit? (I could also do this as follow up, if I don't forget.)

[kfessel]

I believe uncrustify is on a hunt for my coding style

[kaspar030]

I believe uncrustify is on a hunt for my coding style

It's only checking core/ and very few other modules. So touching anything there will probably make it complain, given that the version used in riotdocker is outdated and disagrees with its newer incarnation.

[kfessel]

rebased for the new uncrustify config.
i would happily squash my fixups

[maribu]

some more comments inline

[kaspar030]

this needs uncrustifying

[fjmolinas]

@kfessel missing uncrustify :)

[fjmolinas]

Offline @kaspar030 mentioned this should say it's a show-case of round-robin, and not RIOTs multi-threading since most use cases just follow a priority scheme.

[maribu]

some comments inline

[kfessel]

@fjmolinas shall i squash?

[fjmolinas]

Small nitpicks otherwise this one is fine for me, @maribu is all good on your side?

[fjmolinas]

@kfessel missing uncrustify :)

[maribu]

Code-wise, this looks good to me. Please squash!

[fjmolinas]

ACK from my side.

[fjmolinas]

Some BOARDs need to be added to insufficient memory list, and test is not passing on native

[kfessel]

shall I squash the two fixups?

[benpicco]

Congratulations on landing this!