CyberRT, coroutine to thread mapping

[gusamqq]

As I understand, the mapping from tasks (coroutines) to thread is dynamic at runtime, not static at design time. But this may create problems in timing predictability, since it is difficult or impossible to determine a thread's WCET (worst-case execution time) for real-time schedulability analysis, since you do not know which tasks will be executed in the thread.
Where can I find more details on the task-to-thread mapping algorithm?

[gusamqq]

What is the RTOS (real-time operating system) used underneath CyberRT? Is it developed in-house?

[wutianze]

Same question, I find that cyber RT uses qos in RTPS to maintain communication's qos. But I cannot find RTOS in cyber. Maybe in Apollo kernel? Does Apollo build a customized linux kernel?

[yiakwy]

@wutianze @gusamqq @quning18 There is RT Linux, i.e, with RT patch. you can compile Linux to real time one, so that you can create thread with specified priority, stack size and that which will not be interrupted by other threads.

This is done in "SetSchedPolicy"

https://github.com/yiakwy-mapping-team/cybertron/blob/master/modules/scheduler/common/pin_thread.cc

The file also includes "sched.h" for allocating RT thread and task. Also see apollo-kernel : the default RT OS is Linux with RT patch.

In cybertron, if I understand right, they are physical thread. The project instead uses user - space thread (see bthread and brpc by Ge jun) to allocating tasks in user space.

Here is the so called "processor" to run bthread task with a classical ThreadPool model:

"https://github.com/yiakwy-mapping-team/cybertron/blob/master/modules/scheduler/processor.h"

Here is an simple example:

// after initialize a scheduler instance, for example SchedulerClassic instance, 
// it will create physical processors (real time pthread) internally
auto sched = dynamic_cast<SchedulerClassic>KlassRegistry.getInstance("SchedulerClassic");

// then it will digest user space thread `cr` later by calling "DispatchTask". 
sched->DispatchTask(cr);

As you have noticed in the source code, native thread polling is also supported by scheduler and it is apprent that user tasks are scheduled in user space and have nothing to do with kernel native scheduler.

However there are things I have also noticed:

1. there are containers allocated in heap with STL containers, though some of them are created by "std::array": unpredicted requests to kernel
2. frequent use of mutex to manipulate those STL containers : I am not sure wether or not real time tasks will be affected by mutex synchronization, but of course it will be better to employ atomic container to reduce synchronization latency and number of interaction with kernel.

Wish my answer settle down your question.

[daohu527]

Closed due to inactivity. If the problem persists, pls feel free to reopen it or create a new one and refer to it.