Jan Kiszka wrote:
> Gilles Chanteperdrix wrote:
>> Jan Kiszka wrote:
>>
>> Same remark for the #ifdefs.
>
> Yes, but most cases (maybe except for owner checking) are unavoidable
> due to heavy differences. I hope that we may have only FASTXNSYCH archs
> one day.
>
>> I also do not understand your modification
>> of rt_cond_wait_inner, this code is very tense; posix and native had the
>> same bug in this area at different times, so this change should probably
>> be made separately.
>
> Which modification precisely (damn, I need to find out what makes quilt
> cause this attachment confusion)? Note that lockcnt tracking changed
> with this patch: the lock owner himself is in charge of maintaining it,
> not some thread handing the lock over.
>
> That said, I would happily analyse the case that broke before. I will
> also check if I can break out the lockcnt maintenance change, but I
> think to recall that it was coupled to the fast path changes.
The point is that in case of rt_cond_wait, the mutex must unlock
completely regardless of the current lock count. So, the count is set to
1 before calling the function which unlocks the last level of the
recursion count. As far as I can see, you removed the part which sets
the counter to 1.
--
Gilles.
_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
