Re: [Xenomai-help] Issue with Auto relax and nested mutexes

[Philippe Gerum <rpm@xenomai.org>]

On 01/10/2012 04:51 PM, Makarand Pradhan wrote:
> Based on my testing, it is noted that the rescnt is not released when 
> task1 gets a priority boost and starts running with priority 1. That's 
> when the rescnt is not decremented.
> 
> It would imply that we may be checking the current priority while 
> testing if we want to invoke rt_mutex_release in kernel. Will try to 
> check it out.

Does this help in your case?

diff --git a/include/nucleus/sched-rt.h b/include/nucleus/sched-rt.h
index cc1cefa..6ac8fd7 100644
--- a/include/nucleus/sched-rt.h
+++ b/include/nucleus/sched-rt.h
@@ -87,7 +87,7 @@ static inline void __xnsched_rt_setparam(struct xnthread *thread,
 {
 	thread->cprio = p->rt.prio;
 	if (xnthread_test_state(thread, XNSHADOW)) {
-		if (thread->cprio)
+		if (thread->bprio || !xnthread_test_state(thread, XNBOOST))
 			xnthread_clear_state(thread, XNOTHER);
 		else
 			xnthread_set_state(thread, XNOTHER);
> 
> Rgds,
> Mak.
> 
> On 10/01/12 10:42 AM, Philippe Gerum wrote:
>> On 01/10/2012 04:40 PM, Philippe Gerum wrote:
>>> On 01/10/2012 04:40 PM, Makarand Pradhan wrote:
>>>> Another point:
>>>>
>>>> "These are fast mutexes, the thread does not have to jump to kernel 
>>>> space
>>>> unless the released mutex was actually contented."
>>>>
>>>> When the first task is started with prio 0, I always see that
>>>> rt_mutex_release is invoked in the kernel. even when there is no
>>>> contention.
>>> I should have added: "unless there is no contention ... or the caller is
>>> a non-rt thread". This is because we have to jump to kernel space to
>>> track rescnt.
>>>
>> Ok, next try: "unless the mutex was contented ... or the caller is
>> a non-rt thread".
>>
>>>> I have an instrumented kernel. The kernel trace is given below. In this
>>>> trace only task1 is running at prio 0. It should be easy to follow:
>>>>
>>>> Jan 10 10:36:59 ruggedcom kernel: lo: rescnt: 0, switched: 0
>>>> Jan 10 10:36:59 ruggedcom kernel: hi: rescnt: 0, switched: 0
>>>> Jan 10 10:36:59 ruggedcom kernel: lo: rescnt: 1, switched: 1
>>>> Jan 10 10:36:59 ruggedcom kernel: hi: rescnt: 2, switched: 0
>>>> Jan 10 10:36:59 ruggedcom kernel: hi: rescnt: 3, switched: 0
>>>> Jan 10 10:37:01 ruggedcom kernel: hi: rescnt: 3, switched: 0
>>>> Jan 10 10:37:01 ruggedcom kernel: __rt_mutex_release
>>>> Jan 10 10:37:01 ruggedcom kernel: RML
>>>> Jan 10 10:37:01 ruggedcom kernel: rt_mutex_release: lockcnt: 1
>>>> Jan 10 10:37:01 ruggedcom kernel: xnsynch_release_thread: BP: 0
>>>> Jan 10 10:37:01 ruggedcom kernel: hi: rescnt: 2, switched: 0
>>>> Jan 10 10:37:01 ruggedcom kernel: __rt_mutex_release
>>>> Jan 10 10:37:01 ruggedcom kernel: RML
>>>> Jan 10 10:37:01 ruggedcom kernel: rt_mutex_release: lockcnt: 1
>>>> Jan 10 10:37:01 ruggedcom kernel: xnsynch_release_thread: BP: 0
>>>> Jan 10 10:37:01 ruggedcom kernel: hi: rescnt: 1, switched: 0
>>>> Jan 10 10:37:01 ruggedcom kernel: __rt_mutex_release
>>>> Jan 10 10:37:01 ruggedcom kernel: RML
>>>> Jan 10 10:37:01 ruggedcom kernel: rt_mutex_release: lockcnt: 1
>>>> Jan 10 10:37:01 ruggedcom kernel: xnsynch_release_thread: BP: 0
>>>> Jan 10 10:37:01 ruggedcom kernel: hi: rescnt: 0, switched: 0
>>>> Jan 10 10:37:01 ruggedcom kernel: lo: rescnt: 1, switched: 1
>>>> Jan 10 10:37:01 ruggedcom kernel: hi: rescnt: 2, switched: 0
>>>> Jan 10 10:37:01 ruggedcom kernel: hi: rescnt: 3, switched: 0
>>>> Jan 10 10:37:03 ruggedcom kernel: hi: rescnt: 3, switched: 0
>>>> Jan 10 10:37:03 ruggedcom kernel: __rt_mutex_release
>>>> Jan 10 10:37:03 ruggedcom kernel: RML
>>>> Jan 10 10:37:03 ruggedcom kernel: rt_mutex_release: lockcnt: 1
>>>> Jan 10 10:37:03 ruggedcom kernel: xnsynch_release_thread: BP: 0
>>>> Jan 10 10:37:03 ruggedcom kernel: hi: rescnt: 2, switched: 0
>>>> Jan 10 10:37:03 ruggedcom kernel: __rt_mutex_release
>>>> Jan 10 10:37:03 ruggedcom kernel: RML
>>>> Jan 10 10:37:03 ruggedcom kernel: rt_mutex_release: lockcnt: 1
>>>> Jan 10 10:37:03 ruggedcom kernel: xnsynch_release_thread: BP: 0
>>>> Jan 10 10:37:03 ruggedcom kernel: hi: rescnt: 1, switched: 0
>>>> Jan 10 10:37:03 ruggedcom kernel: __rt_mutex_release
>>>> Jan 10 10:37:03 ruggedcom kernel: RML
>>>> Jan 10 10:37:03 ruggedcom kernel: rt_mutex_release: lockcnt: 1
>>>> Jan 10 10:37:03 ruggedcom kernel: xnsynch_release_thread: BP: 0
>>>> Jan 10 10:37:03 ruggedcom kernel: hi: rescnt: 0, switched: 0
>>>> Jan 10 10:37:03 ruggedcom kernel: lo: rescnt: 1, switched: 1
>>>> Jan 10 10:37:03 ruggedcom kernel: hi: rescnt: 2, switched: 0
>>>> Jan 10 10:37:03 ruggedcom kernel: hi: rescnt: 3, switched: 0
>>>> Jan 10 10:37:04 ruggedcom kernel: hi: rescnt: 3, switched: 0
>>>>
>>>>
>>>> root@domain.hid:~# ./a.out 0 1
>>>> Spawning: tasks
>>>> bP: 0, cp: 0, mode: 0
>>>> Acquire complete
>>>> Release complete
>>>> bP: 0, cp: 0, mode: 0
>>>> Acquire complete
>>>> Release complete
>>>> bP: 0, cp: 0, mode: 0
>>>> Acquire complete
>>>> ^C
>>>>
>>>>
>>>> Rgds,
>>>> Mak.
>>>>
>>>>
>>>>
>>>> On 10/01/12 10:26 AM, Makarand Pradhan wrote:
>>>>> Hi Phillippe,
>>>>>
>>>>> You are right. Task 1 requires to be started with prio 0. I start 
>>>>> seeing
>>>>> the problem after task2 grabs the mutex and releases them. The first
>>>>> task never jumps back to seconodary. Here is my output. The mode never
>>>>> goes back to 0 after "Grabbing mux in HP" and the rescnt stays 
>>>>> stuck at
>>>>> 1 in the kernel.
>>>>>
>>>>> root@domain.hid:~# ./relax 0 1
>>>>> Spawning: tasks
>>>>> bP: 0, cp: 0, mode: 0
>>>>> Acquire complete
>>>>> Release complete
>>>>> bP: 0, cp: 0, mode: 0
>>>>> Acquire complete
>>>>> Release complete
>>>>> bP: 0, cp: 0, mode: 0
>>>>> Acquire complete
>>>>> Release complete
>>>>> bP: 0, cp: 0, mode: 0
>>>>> Acquire complete
>>>>> Grabbing mux in HP
>>>>> Mux held by Task2
>>>>> Release complete
>>>>> bP: 0, cp: 0, mode: 1
>>>>> Acquire complete
>>>>> Release complete
>>>>> bP: 0, cp: 0, mode: 1
>>>>> Acquire complete
>>>>>
>>>>> Rgds,
>>>>> Mak.
>>>>>
>>>>>
>>>>> On 10/01/12 10:11 AM, Philippe Gerum wrote:
>>>>>> On 01/09/2012 09:50 PM, Makarand Pradhan wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> I am running kernel 3.0.0, xenomai: 2.6, powerpc 8360.
>>>>>>>
>>>>>>> I am noticing an issue while using the auto relax feature related to
>>>>>>> mutexes. I am using nested mutexes. The code is attached to this
>>>>>>> email.
>>>>>>>
>>>>>>> The problem is that I am not relaxing after a RT thread grabs and
>>>>>>> releases a mutex. On further investigation, it was noted that the
>>>>>>> rescnt
>>>>>>> is not going down to 0.
>>>>>> From your code, task1 would auto-relax only if started with 
>>>>>> priority 0,
>>>>>> which is what I get here:
>>>>>>
>>>>>> -bash-3.2# ./relax 0 1
>>>>>> Spawning: tasks
>>>>>> bP: 0, cp: 0, mode: 0
>>>>>> Acquire complete
>>>>>> Release complete
>>>>>> bP: 0, cp: 0, mode: 0
>>>>>> Acquire complete
>>>>>> Release complete
>>>>>> bP: 0, cp: 0, mode: 0
>>>>>> Acquire complete
>>>>>> Release complete
>>>>>> ...
>>>>>>
>>>>>> Conversely, I get the right behavior if setting a non-zero 
>>>>>> priority to
>>>>>> task1:
>>>>>>
>>>>>> -bash-3.2# ./relax 1 0
>>>>>> Spawning: tasks
>>>>>> bP: 1, cp: 1, mode: 1
>>>>>> Acquire complete
>>>>>> Release complete
>>>>>> bP: 1, cp: 1, mode: 1
>>>>>> Acquire complete
>>>>>> Release complete
>>>>>> bP: 1, cp: 1, mode: 1
>>>>>> Acquire complete
>>>>>> ...
>>>>>>
>>>>>> In any case, the priority of task2 should have no impact on the 
>>>>>> result.
>>>>>>
>>>>>> I'm running current 2.6 HEAD commit (168da46de), kernel 
>>>>>> 3.1.5/powerpc32
>>>>>> (52xx), pipeline 2.13-06.
>>>>>>
>>>>>> Which priority arguments are you passing to your test program?
>>>>>>
>>>>>>> Another observation is that I do not hit
>>>>>>> rt_mutex_release in the kernel in the problem scenario, I believe 
>>>>>>> when
>>>>>>> the thread undergoes a priority inversion.This may be a problem 
>>>>>>> as the
>>>>>>> rescnt would not get decremented. Not sure how the mutex is 
>>>>>>> releasing
>>>>>>> wiithout hitting rt_mutex_relase or am I missing anything?
>>>>>>>
>>>>>> These are fast mutexes, the thread does not have to jump to kernel
>>>>>> space
>>>>>> unless the released mutex was actually contented.
>>>>>>
>>>>>>> If I have both the tasks running at priority 0, I stay in the
>>>>>>> secondary
>>>>>>> domain, rt_mutex_release is invoked as expected, the rescnt goes
>>>>>>> down to
>>>>>>> 0 when all the mutexes are released.
>>>>>>>
>>>>>>> Has anyone faced this problem?
>>>>>>>
>>>>>> I'm unsure there is any yet. Auto-relax applies to non -rt Xenomai
>>>>>> threads only (i.e. prio == 0).
>>>>>>
>>>>>>> Rgds,
>>>>>>> Makarand
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Xenomai-help mailing list
>>>>>>> Xenomai-help@domain.hid
>>>>>>> https://mail.gna.org/listinfo/xenomai-help
>>>>
>>>
>>
> 
> 


-- 
Philippe.