Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>> Gilles Chanteperdrix wrote:
>>> Jan Kiszka wrote:
>>>> Here comes a significantly reworked patch series to improve fast mutex
>>>> support of Xenomai.
>>>> This approach now introduces a generic fast xnsynch core and converts
>>>> the existing POSIX implementation over. It also comes with a second
>>>> user, the Native skin. Additionally, it improves xeno_get_current via
>>>> a TLS variable and addresses the issue that threads in secondary mode
>>>> acquiring an uncontended mutex need to be migrated first.
>>>> At this chance, the TLS optimization is also applied on self-lookups of
>>>> task handles (Native, VRTX and VxWorks). And I included my
>>>> SMP-by-default patch for user libs which is highly recommended to reduce
>>>> the risk of accidental code breakage on SMP with the new mutex code.
>>> A minor remark. This is the third round of patches for fast mutexes, and
>>> each round, you submit even more changes to review than the previous
>>> round. If I doubted of your honesty, I could think that you are trying
>>> to dilute some questionable changes into more changes so that they get
>> May I recall the changelog of this round? In short:
>> - generic xnsynch
>> - fixed prio-inversion when coming from secondary mode
>> These are major changes, addressing specifically the NACKs of the
>> previous rounds.
>> If you find "questionable changes", please point them out. So far I only
>> recall the discussion about lockcnt maintenance policy, and I will try
>> to sort that one out.
> The problem is that it took me about one hour reviewing your 12 patches
> (I know, I am a slow guy), and that I am not even sure that I saw all
> the changes.
I appreciate your effort very much, and you already provided valuable
input. But I feel it is much better to have the full picture instead of
scattered bits. And this 12 patches belong together until none of their
features are merged.
> The lockcnt change in patch 8 for instance is not even mentioned in the
> patch comments, and it is only because I originally did not understand
> the change in rt_cond_wait_inner that I now know about this change.
Sorry for that, but it fell under the table on which all the other
significant changes were already lying. Moreover, I originally felt it
was only a minor cleanup as I simply aligned the code to the POSIX
implementation in this regard. Nevertheless, the next posting will
contain a separate patch for this.
>>> Could we focus on a small set of changes, reach consensus, merge them,
>>> and then move to the next set of changes?
>> No problem. Maybe I missed or forgot the clear OK for patches 1..4 to
>> commit them, but I will now soon. Moreover, I just felt uncomfortable
>> with merging patch 5 without having written to following ones.
> I think Philippe should merge the patches.
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux
Xenomai-core mailing list