[LITMUS^RT] Synchronization of resources

[Björn Brandenburg]

> 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/251bcf63/attachment.html>