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