[LITMUS^RT] Synchronization of resources

[shijunjie92]

Hello:
The reason why I ask the last question is that I am trying to implement the 'help mechanism' of MrsP.
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?)

Best Wishes!




You Sincerely!
SHI Junjie

2016-08-30 

shijunjie92 



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



On 30 Aug 2016, at 15:21, shijunjie92 <shijunjie92 at gmail.com> wrote:


When we simulate the critical section within one task using 'rtspin'. We will enter the resource id. But there is no such id information included by semaphore. So how can we know the semaphore locks which resource. (Different resources use different wait_queues?)


The FDSO interface (“file-descriptor-attached shared objects”) maps the user-space provided IDs to objects. To share a semaphore between two processes, both need to open the same file (= name space), and reference the same ID (= index in object table attached to file). 


Why the function pfp_mpcp_lock( as well as other lock function) calls 'init_waitqueue_entry' everytime when the resource is occupied. When more then two tasks try to get the resource, the wait_queue will be initialized more than once? How to explain that?



It initializes a wait queue *entry*, not the entire wait queue. Every blocked task allocates such an entry on its stack.


The last question is about the MPCP_VS protocol in P-FP plugin.
When we use MPCP_VS protocol:
cpu_0: task_0 is excuting by holding the resource_0 
cpu_1: task_1 is excuting by holding the resource_1 
cpu_2: task_2 is spinning but not excuting for waitting one resource (resource_0 or resource_1)

Now, task_0 is preempted by one higher priority task, but it still hold the semaphore of resource_0.



Isn’t a resource-holding task priority-boosted?


Is there any possible that lets task_0 know whether the task_2 is waitting for resource_0 or resource_1 or not?


In the kernel, you can always lock and look at the wait queue associated with the semaphore. All tasks blocked on the lock are queued.


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