Jan Kiszka wrote:
> Gilles Chanteperdrix wrote:
>> Jan Kiszka wrote:
>>> Gilles Chanteperdrix wrote:
>>>> Jan Kiszka wrote:
>>>>> Gilles Chanteperdrix wrote:
>>>>>> Jan Kiszka wrote:
>>>>>>> + xnarch_atomic_set(mutex->owner,
>>>>>>> + set_claimed(xnthread_handle(owner),
>>>>>>> +
>>>>>>> xnsynch_nsleepers(&mutex->synchbase)));
>>>>>> Ok. I think you have spotted a bug here. This should be mutex->sleepers
>>>>>> instead of xnsynch_nsleepers.
>>>>> BTW, why do you need to track sleepers separately in POSIX? Native
>>>>> doesn't do so, e.g.
>>>> Because of the "syscall-needed-when-unlocking-stolen-mutex" issue I
>>>> already explained (sleepers - xnsynch_nsleepers is precisely the count
>>>> of pending threads which have been awake then robbed the mutex).
>>> Hmm, sounds like the new lock owner should better clear the 'claimed'
>>> bit then, not the old one on return from unlock. Or where is the
>>> pitfall? How does the futex algorithm handle this scenario?
>> Ok. Please read my explanation again, I have already explained this in
>> another mail.
>
> I did this, but I'm unable to derive the answer for my question from it.
> Let's go through it in more details:
>
> When we pass a mutex to a new owner, we set its reference in the fast
> lock variable + set the claimed bit if there are more waiters. Instead,
> I would simple set that bit if there is a new owner. That owner will
> then pick up the mutex eventually and clear 'claimed' on exit from it
> lock service (if there are no further waiters then). If the new owner is
> not able to run and we steal the lock, we simple keep the 'claimed' bit
> as is. On exit from the stolen lock we find it set, thus we are forced
> to issue a syscall as it should be.
>
> OK, what happens if some waiter wants to leave the party while we are
> holding the stolen lock? Then the sleeper number must be correct - that
> is one pitfall!
>
> I will have to dig into this more deeply, considering more cases. But
> the additional "sleepers" field remains at least misplaced IMHO.
> xnsynch_sleepers should better be fixed to respect lock stealing, as
> lock stealing is an xnsynch property, nothing POSIX-specific.
Ok. I have read this but did not get what you mean. I will read it again
quietly from home.
--
Gilles.
_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
