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.


Xenomai-core mailing list

Reply via email to