[LITMUS^RT] How to handle the blocked task

[Björn Brandenburg]

> On 07 Oct 2016, at 06:14, shijunjie92 <shijunjie92 at gmail.com> wrote:
> 
> Hello:
>  
> Druing the implementation of the MrsP. I need to build the ceiling for each cpu. All the tasks' priority lower than the ceiling are not allowed to execute. So the following situation may occur: one task holds the ceiling but is blocked by waiting resource. There are some normal tasks which are not waiting for resource in that cpu. They are not allowed to execute because their's priorities are lower than the ceiling. That means this cpu is idle eventhough there are some tasks are ready to execute. In that situation, how can I deal with the logic inside the pfp_schedule(). Can I set the next as NULL to set the cpu in idle state?\

If you return NULL, then the CPU is idled from the point of view of LITMUS^RT and the regular Linux scheduler takes over to schedule background tasks.

However, why do you need to stop lower-priority tasks from executing? That doesn’t make much sense to me. If they don’t request any resources, there shouldn’t be any problems. Can’t you let them run and block them only when they actually try to lock something? The MPCP-VS works exactly like this and is already implemented in LITMUS^RT, maybe you can use a similar approach?

> Another question is about the cpu_ceiling. In the multiprocessor environment, different semaphores can be allocated to different processors, which can update the loacl cpu ceiling. How can I deal with such data transmission between different semaphore and different processors? Add the structure mrsp_semaphore and mrsp_state into the pfp_domain_t or you have other effective solution? 

There are already implementations of the PCP and the SRP; both deal with per-processor ceilings.

- Björn