Adaptive scheduler for C target

[petervdonovan]

To clarify -- this is the scheduler that previously had the vague name "heuristic."

This scheduler is written in response to poor scaling behavior wrt number of threads in our Savina benchmarks. It achieves good performance on these benchmarks, but it is uncertain whether this good performance will generalize beyond them.

Some notes:

• These graphs are not the most up-to-date, but they should be close enough. A-Star has a known bug, so scaling behavior in that benchmark probably can be ignored.
• Some of the logic implemented here, in the main LF repo, has to do with finding the files related to a particular pluggable scheduler. It may soon be deleted anyway, for we may choose to refactor to use CMake for that sort of thing.
• Other schedulers which we should implement soon will hopefully replace this scheduler for at least some use cases. Annotations that specify order-of-magnitude estimates of reaction WCETs may in some applications replace the experiments that this scheduler does at runtime. Some of the strategies implemented by this scheduler may also be realizable without sacrificing the worst-case execution time of levels. Furthermore, schedulers ideally should not rely on levels, as this scheduler does. They should have chain ID (or something like it) and LET instead.
  • This is relevant because it means I regard this scheduler as experimental and argue that its general level of quality may not be as critical as in e.g. the GEDF scheduler.

[Soroosh129]

It looks like the Windows tests are failing because of a path-related issue:

A required target resource could not be found: /lib/c/reactor-c/core/threaded\scheduler_NP.c

[Soroosh129]

LGTM! Thanks for cleaning up the logic in the validator.

[Soroosh129]

This line seems to not be necessary for the adaptive scheduler since scheduler.getRelativePaths() already includes this. Would it make sense to have all these files added in the enum constructor for all schedulers?

[petervdonovan]

Oh, good catch... I'll fix that. The other three files -- scheduler.h, scheduler_instance.h, and scheduler_sync_tag_advance.c -- are currently used by all schedulers, I think, so to me it seems reasonable to limit redundancy by keeping them here.

(BTW, I have for a while been making noises about factoring this logic out into CMake files, so if others agree with me then this code might not be here for long anyway.)

Edit: The adaptive scheduler doesn't use scheduler_instance.h, actually, but I think it's harmless to copy it into the src-gen directory. I don't think doing so has any effect on the executable produced.

[Soroosh129]

Factoring this logic out into CMake files

This sounds like a great idea. Are you imagining each scheduler having a separate CMakeLists.txt or one CMakeLists.txt for all the schedulers?

One thing to keep in mind is that we should still be able to accommodate cmake: false (i.e., building without CMake).

[petervdonovan]

How important is it to accommodate cmake: false? Maybe this isn't the place to have this discussion, but I am not aware of use-cases for cmake: false, and what I was talking about was basically to do away with it. Do we maintain it just for fun?

[Soroosh129]

It’s for embedded systems, particularly bare-iron, that don’t necessarily have a supported CMake-based workflow.