Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>> Gilles Chanteperdrix wrote:
>>> Jan Kiszka wrote:
>>>> @@ -329,6 +326,13 @@ int pse51_mutex_timedlock_break(struct _
>>>>                            break;
>>>>                    }
>>>>            }
>>>> +          if (!xnsynch_nsleepers(&mutex->synchbase)) {
>>>> +                  xnarch_atomic_set
>>>> +                          (mutex->owner,
>>>> +                           clear_claimed
>>>> +                                  (xnarch_atomic_get(mutex->owner)));
>>>> +                  xnsynch_set_owner(&mutex->synchbase, NULL);
>>>> +          }
>>>>            xnlock_put_irqrestore(&nklock, s);
>>> I do not like this at all. I mean, unless I am mistaken, we loose more
>>> than we gain, we are adding a couple of atomic, hence heavy, operations
>>> in a common case for handling a corner case. I still prefer emitting a
>>> system call in the corner case.
>> The hunk above is in the mutex' deadlock path - I wouldn't call this a
>> common case. Moreover, we don't any expensive cmpxchg here.
>> I haven't counted ops, but my strong feeling is that this patch actually
>> shortens the common code paths + it safely avoids one syscall in the
>> lock stealing case.
> I have not yet understood how this happens.

Argh, it won't work for all cases: When the robbed owner retries the
acquisition while the current owner still holds the lock, that clearing
of xnsynch_owner has the fatal effect of letting the former thread
proceed as well. So we cannot get around to extend xnsynch, teaching it
about the two-level ownership management - or actually folding fast lock
support into xnsynch.


Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux

Xenomai-core mailing list

Reply via email to