Is there a need for a multi-task scheduler for an xcore?

[Heater]

Is there a need for a small, simple, fast cooperative scheduler for XC?

mculibrk recently posed a question here regarding processor speed and thread priority https://www.xcore.com/forum/viewtopic.php?f=10&t=1162

This started me thinking...

1) Let's assume there is at least one thread in my application that really needs the full execution speed of the xcore that is possible. Perhaps handling some external device that demands high speed servicing.

2) Let's assume the application is such that it best structured as many threads, greater than 4. And that these additional threads are not under such strict timing requirements as in 1)

What we know is that when we have from 1 to 4 threads they all get the maximum speed achievable on the xcore. When we add a 5th thread performance drops by 25%. Add another and it drops the same amount again. Etc.

Thus building our app using many xcore threads as required by 2) breaks the performance requirements of 1).

One way out of this bind is to:

1) Ensure there are never more than 4 threads running. Thus extracting maximum performance.

2) Combine the less time critical threads into one (or more) xcore threads.

Of course 2) could be done by coding the app such that multiple threads work is combined at the app source code level.

But it occurs to me that a traditional multi-tasking scheduler would be a better way to go for those slower app threads. Basically juggling app threads on a single xcore thread whilst the time critical stuff happens on one or more other xcore threads.

OK a long way to ask a simple question. Is there such a scheduler for xcore? Is one under construction some where?

Or am I missing a point and there is a better way to do this?

[daveg]

Is there a need for a small, simple, fast cooperative scheduler for XC?

...

But it occurs to me that a traditional multi-tasking scheduler would be a better way to go for those slower app threads. Basically juggling app threads on a single xcore thread whilst the time critical stuff happens on one or more other xcore threads.

OK a long way to ask a simple question. Is there such a scheduler for xcore? Is one under construction some where?

Or am I missing a point and there is a better way to do this?

There are a couple of projects on here which have done similar things to this (FreeRTOS project, for example), but there is no "official" way to do this automatically yet. If you have non-time-critical stuff then merging this into a simple round-robin scheduler should be straightforward, but most code tends to be time critical in one way or another (e.g. buffering for another hardware thread still needs to be "fast enough").

[mculibrk]

There are a couple of projects on here which have done similar things to this (FreeRTOS project, for example), but there is no "official" way to do this automatically yet. If you have non-time-critical stuff then merging this into a simple round-robin scheduler should be straightforward, but most code tends to be time critical in one way or another (e.g. buffering for another hardware thread still needs to be "fast enough").

Such a scheduler should be really nice indeed. Making it a library with a few API calls for starting/stopping/checking those "sub-threads"...

I agree that

but most code tends to be time critical in one way or another

but the programmer actually knows that and it has at least 3 deterministic threads per core for such tasks...

..sure, my first thought was to ask if there is a way to set priority in hardware instead of thinking to implement/use some soft-scheduler... lazy me... :D

[mculibrk]

...after a quick look at the FreeRTOS port it seems "already done" :idea:

It's really simple and straightforward. The whole thing could be stripped down to the bare minimum (and just use the scheduler), implement that as a "standalone" thread and maybe use channels to start/stop "sub-threads" on the fly.

One of the issues I see is some nice "integration" in the XC scheme and "libraries"...
in XC you cannot get "pointers to functions" etc nor pass "functions as parameters" so this should be done in C. And all calls to start/stop should be handled by C (as I see it right now) which would be not so readable/nice from the programming perspective.
And then there is the issue of kernel mode which is used and I did not checked (jet) in some XC disassembly... but it shuld be absolutely doable.

nice!

regards,
mculibrk

[daveg]

...after a quick look at the FreeRTOS port it seems "already done" :idea:

It's really simple and straightforward. The whole thing could be stripped down to the bare minimum (and just use the scheduler), implement that as a "standalone" thread and maybe use channels to start/stop "sub-threads" on the fly.

One of the issues I see is some nice "integration" in the XC scheme and "libraries"...
in XC you cannot get "pointers to functions" etc nor pass "functions as parameters" so this should be done in C. And all calls to start/stop should be handled by C (as I see it right now) which would be not so readable/nice from the programming perspective.
And then there is the issue of kernel mode which is used and I did not checked (jet) in some XC disassembly... but it shuld be absolutely doable.

This sounds more like asynchronous threads, which XC doesn't support, so even if there was a flag to set a par as non-hardware then it would be unlikely to work in the function-pointer and start/stop function way; this is more akin to pthreads in C (but this would still require some tools support to work correctly with certain optimizations).

[mculibrk]

This sounds more like asynchronous threads, which XC doesn't support, so even if there was a flag to set a par as non-hardware then it would be unlikely to work in the function-pointer and start/stop function way; this is more akin to pthreads in C (but this would still require some tools support to work correctly with certain optimizations).

Absolutely! It would be a "poor men solution" to have high-priority guaranteed execution of some threads and a "shared pool of asynchronous threads" working on some less-demanding tasks, not time critical etc.

After some more thoughts the whole "soft-threads stuff" would be rather difficult to "cleanly implement" in XC.
By using "mixed" hardware and shared/software threads a whole pile of problems arise - resource usage, channels, ports etc
and I see no "transparent" way of using that in the code (to keep identical syntax/look&feel of the standard XC).

Would it be even possible to use channel for communication inside the same thread??? I mean - on the HW lavel.
You have to set the destination for the chanend... but will it accept a chanend in the same hw thread as destination?

And then... problems with events... if the scheduler "changes" the soft thread during a select strange things would happen...

So... it is possible/usable but great care should be taken during programming... and at the end, is it worth the effort?

regards,
mculibrk