Scheduler in SMP

[Joel Sherrill]

On 09/29/2012 05:42 AM, Matias Vara wrote:
>
> 2012/9/28 Joel Sherrill <joel.sherrill at oarcorp.com 
> <mailto:joel.sherrill at oarcorp.com>>
>
>     On 09/28/2012 02:28 PM, Matias Vara wrote:
>
>         Hi everyone,
>
>         I am playing with the samples of RTEMS for SMP. I am trying
>         understand the example in /smp01, this one creates one task
>         per processor but I cannot figure out how the task is set in a
>         given processor. Are there any parameter when the task is created?
>
>
>     This would be called task processor affinity and it is not currently
>     supported. It was left as a future enhancement.
>
>     The current smptests were not designed to show off smp but to
>     debug it and to get coverage.
>
>     The magic of assigning a task to a core is in the scheduler. It is
>     in cpukit/score/src/schedulersimplesmp*. It is logically intended to
>     be the same as the single core scheduler but place the top N
>     tasks onto the N cores. It takes into account priority, preemption,
>     FIFO per priority, and timeslicing just like the single core priority
>     scheduler does.
>
>
> It is clear now, thanks for the answer!
> Following the subject, then there is a one queue of task per processor?
Not in the Simple SMP Scheduler. Each Scheduler implementation is free to
use whatever data structures it needs. The framework for Schedulers is
event driven. The primary events are when a task blocks, is unblocked,
and at each clock tick. A Scheduler then does what it needs to do to
determine which threads are the "heirs" for each core. If that decision
results in the need to replace the executing thread on a core, then
that a context switch is needed and the dispatcher will be invoked
to handle that part.

Logically in RTEMS there are sets of tasks.

+ One set of executing tasks
+ One set of ready tasks
+ Multiple sets of blocked tasks (one set per resource)

Depending on the scheduling algorithm, the set of executing tasks
may or may not be included in the data structure for the ready set.

Moving tasks between the sets and determining which ready tasks
to execute is conceptually the foundation of RTEMS. You just have various
resources (e.g., mutexes, message queues, delays, barriers, etc.)
tasks can block on which give you different communication and
synchronization patterns to build applications upon.

> The tasks are queued at the running time (when task_create is 
> invoked)? If they're queued at running time I suppose the access to 
> such queue is atomic.
>
Tasks are queued and dequeued from the ready set when they block or are
unblocked.[1] With Classic API tasks, you have to also do a task_start 
to get
them into a ready state. With pthreads, pthread_create places the thread in
a ready state.

The operation had better be atomic. :)



(1) When a task changes priority, it is implicitly blocked and then 
unblocked.
> Thanks in advance, Matias.
>
>
>
> -- 
> MV