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
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.
> 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.
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux
Xenomai-core mailing list