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@ruggedcom:~# ./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@ruggedcom:~# ./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@gna.org https://mail.gna.org/listinfo/xenomai-help
-- Philippe. _______________________________________________ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
