Jan Kiszka wrote:
> Slowly moving on toward generic fast mutex support for Xenomai, this
> patch is a proposal to address the increasing divergence of
> owner-tracking vs. owner-less xnsynch objects.
> 
> The services dealing with the former will likely include a new, lockless
> prologues for the mutex fastpath. At the the same time, this additional
> code should not disturb too much in those cases where we do not track
> ownership (condition variables, events, semaphores etc.). Moreover, I
> noticed that some of the existing code assumes XNSYNCH_NOPIP means no
> ownership, which is surely not true. The already visible effect is that
> lock stealing is needlessly restricted to XNSYNCH_PIP.
> 
> Going through the API, I dug out three diverging services and replaced
> them with two new ones:
> 
> Owner-less xnsynch objects:
> - xnsynch_sleep_on
> - xnsynch_wakeup_one_sleeper
> - xnsynch_wakeup_this_sleeper
> 
> Owner-tracking xnsynch objects:
> - xnsynch_acquire
> - xnsynch_release
> 
> The latter type of objects are marked with the new flag XNSYNCH_OWNER,
> used only for debugging and code documentation purposes in the current
> implementation.

Any comments on this? I plan to resume the work on fast xnsynch once
this building block is clarified (or replaced by an alternative).

Jan

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Reply via email to