[LITMUS^RT] Synchronization of resources

shijunjie92 shijunjie92 at gmail.com
Tue Aug 30 20:22:57 CEST 2016


Thank you very much for your help! I am interested in that implementation. I will appreciate that if you can share it to me.
Best Wishes!




You Sincerely!
SHI Junjie
E-mail: shijunjie92 at gmail.com


2016-08-30 

shijunjie92 



发件人:Björn Brandenburg <bbb at mpi-sws.org>
发送时间:2016-08-30 19:13
主题:Re: [LITMUS^RT] Synchronization of resources
收件人:"litmus-dev"<litmus-dev at lists.litmus-rt.org>
抄送:



On 30 Aug 2016, at 20:00, shijunjie92 <shijunjie92 at gmail.com> wrote:


The reason why I ask the last question is that I am trying to implement the 'help mechanism' of MrsP.


I haven’t tried implementing the MrsP myself, so I can’t really offer much specific guidance here.


The resource-holding task can be preempted by other higher priority normal execution task, but it still holds the resource. So I need to find out, is there any task in other processor is spinning and waitting for that resource. Sothat this processor can do the 'help'. Of cource, such task have been enqueued on the wait queue of that semaphore. But how can I locate that task when it locates on the middle of that queue?(traverse all the wait queue and compare to all the processors' spinning tasks?)


Good questions. These are exactly the kind of problems why “helping” and “migrate-on-blocking” policies are difficult to implement in a real OS, even though they look very appealing on paper. 


For what it's worth, my MC-IPC implementation requires multiprocessor bandwidth inheritance, which runs into similar problems. It’s not part of the LITMUS^RT mainline version, but if you are interested I can share a version (that hasn’t been cleaned up yet) with you off list. (Of course, you’d get it as it is, no support implied, etc.)


- Björn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.litmus-rt.org/pipermail/litmus-dev/attachments/20160830/bb1811a0/attachment.html>


More information about the litmus-dev mailing list