Re: [Xenomai] Prio ceiling mutex issues

[Jan Kiszka <jan.kiszka@siemens.com>]

On 2016-05-09 21:22, Philippe Gerum wrote:
> On 05/09/2016 09:16 PM, Jan Kiszka wrote:
>> On 2016-05-09 21:03, Jan Kiszka wrote:
>>> Hi Philippe,
>>>
>>> we ran into at least one bug of the current prio ceiling support for
>>> synch objects: on xnsynch_release, we only reschedule if we woken up a
>>> new owner. But we also have to reschedule after dropping the ceiling
>>> prio as some higher prio thread may be waiting.
>>>
>>> For that, I would propose to alter the return type and semantic of
>>> xnsynch_release from "pointer to new owner" into "bool, true if
>>> reschedule is needed". It seems, no caller of xnsynch_release makes a
>>> non-boolean use of the return value anyway. And then we can simply
>>> return true on "synch->status & XNSYNCH_PP".
>>>
>>> That leads to the question what would happen in the fast case. Consider
>>>
>>> pthread_mutex_lock(ceiling_mutex);
>>> wake_up_thread(some_thread); // caller_prio < target_prio < ceiling_prio
>>> pthread_mutex_unlock(ceiling_mutex);
>>>
>>> To my current understanding, there is nothing enforcing a syscall for
>>> the unlock caller if some thread woke up after the lock, thus may have a
>>> high prio after the unlock. Or am I missing something?
>>
>> OK, I think I got it: When we found a reason to reschedule after taking
>> such a ceiling lock lazily, we commit the prio-boost and enforce the
>> kernel exit on release via xnsynch_fast_ceiling in commit_ceiling,
>> right?
> 
> Correct (at the very least this is the intent of the implementation).
> 

Good... I pushed the two patches I have in mind, but both lack testing
beyond "builds for me". I will let them run to our scenario tomorrow
unless you see a problem.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux