Re: [Xenomai-core] [RFC][PATCH] Factor out xnsynch_acquire/release

[Jan Kiszka <jan.kiszka@domain.hid>]

[-- Attachment #1: Type: text/plain, Size: 1338 bytes --]

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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]