----- Ursprüngliche Mail -----
> Von: "Jan Kiszka" <jan.kis...@siemens.com>
>> task5 fails:
>> [9] at task-5.c:79
>> [1] at task-5.c:23
>> [10] at task-5.c:87
>> [3] at task-5.c:40
>> [11] at task-5.c:95
>> [4] at task-5.c:45
>> [5] at task-5.c:50
>> [6] at task-5.c:55
>> [2] at task-5.c:28
>> [7] at task-5.c:60
>> 0"003.160| BUG in __traceobj_check_abort(): [FGND] wrong return
>> status:
>> task-5.c:63 => EINVAL (want OK)
This failure is a little trickier.
Line 62 is:
ret = rt_task_set_priority(&t_bgnd, info.prio + 1);
ret is EINVAL, that's why the assert in line 63 fails.
It fails because t_bgnd has already terminated.
This concurs also with the above marker [2].
[2] is reached when t_bgnd is done.
The foreground task does:
ret = rt_task_inquire(NULL, &info);
traceobj_assert(&trobj, ret == 0 && info.prio == 21);
traceobj_mark(&trobj, 6);
ret = rt_task_set_priority(&t_bgnd, info.prio);
traceobj_check(&trobj, ret, 0);
traceobj_mark(&trobj, 7);
ret = rt_task_set_priority(&t_bgnd, info.prio + 1);
traceobj_check(&trobj, ret, 0);
traceobj_mark(&trobj, 8);
So it asks for it's own priority, it must be 21, that's okay.
Then it raises the priority of t_bgnd from 20 to 21
and assumes that no scheduling happens. But this seems to fail.
Did the nucleus CPU scheduler guarantee that giving another task
the same priority of the calling task will favour the caller?
Now the gifted task seems to win.
Thanks,
//richard
