[LITMUS^RT] How to handle the blocked task

[shijunjie92]

Hello:

What you have implemented in MPCP_VS is 'spin non-preemptively'. What MrsP uses is 'spin at local ceiling priority'. So what I need to do is to change the logic inside the pfp_schedule(). 

2016-10-07 

shijunjie92 



发件人：Björn Brandenburg <bbb at mpi-sws.org>
发送时间：2016-10-07 12:34
主题：Re: [LITMUS^RT] How to handle the blocked task
收件人："litmus-dev"<litmus-dev at lists.litmus-rt.org>
抄送：


> 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 


_______________________________________________ 
litmus-dev mailing list 
litmus-dev at lists.litmus-rt.org 
https://lists.litmus-rt.org/listinfo/litmus-dev 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.litmus-rt.org/pipermail/litmus-dev/attachments/20161007/6969dd32/attachment.html>