Adding a new scheduling algorithm to Fiasco.OC

[Valentin Hauner]

Hi,

On 08/11/2014 11:35 PM, Adam Lackorzynski wrote:
> I'd assume that the ready queue also has moe because moe should be
> ready. Wouldn't, with a requeue, sigma0 moved behind moe now (next
> deadline of sigma0 is further away)? On the other side, sigma0 is not
> done with that single message, so it also should be continuing
> execution. Who's running when the output stops?
>   
Are sigma0 and moe periodic tasks that are active as long as the whole
system is up? Or are they just active during the init phase?

In theory, the ready queue of a EDF scheduler isn't rotated, but
contains all Sched_contexts sorted by their deadlines.
Meanwhile, I have added a separate ready queue for my deadline based
threads. So currently, there are two ready queues: One that contains all
ordinary threads (sigma0, moe etc.) and one that contains my deadline
based threads only.
The ordinary ready queue is rotated with that method mentioned in my
previous mail whenever a requeue request arrives. The deadline ready
queue is not rotated.

Adapted from your fp_wfq example, the thread to run next is determined
as follows:
>[...]
>Ready_queue_edf<E>::next_to_run() const
>{
>  if (!deadlineRq.empty())
>    return deadlineRq.front();
>
>  return rq.front();
>}

I.e. whenever there is a thread in my deadline ready queue, it is chosen
for execution. However, the execution ends up with the following error:

>[...]
>MOE: Hello world
>[...]
>MOE: loading 'rom/ned'
>[...]
>Ned: loading file: 'rom/hello.cfg'
>Inserted id:5 in ordinary rq!
>Inserted id:3 in ordinary rq!
>Inserted id:4 in ordinary rq!
>Inserted id:3 in ordinary rq!
>Inserted id:4 in ordinary rq!
>Inserted id:8 in ordinary rq!
>Inserted id:4 in ordinary rq!
>Inserted id:3 in ordinary rq!
>
>Inserted id:9 with deadline=10 in deadlineRq (content of deadlineRq:
9->end)
>
>Inserted id:8 in ordinary rq!
>
>Got requeue call for id:9 - reinserted!
>./kernel/fiasco/src/kern/thread-ipc.cpp:456: ASSERTION FAILED
(!(state() & Thread_ipc_mask))

I'm assigning identification numbers to the threads in the order of
their creation time. So my two threads launched in hello.cfg are those
with id 9 and 11 (the latter does not appear in the example above).
Consequently, Fiasco creates 8 kernel threads (?) before mine.
Why does that assertion fail? Obviously, some of the kernel threads have
to be executed before, but which? The ordinary ready queue will never
become empty as it is a cyclic queue with rotation.

Best regards,
Valentin