Jan Kiszka wrote:
> 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.
>> Find a first draft of this approach attached (compile-tested). Before
>> going down this round, I would like to collect opinions and finally an
>> Ack on this (or and alternative approach). I also briefly thought about
>> branching two xnsynch sub-objects for owner/no-owner. But that would
>> likely make the changes far more complicated and invasive.
> Forgot to mention that the patch applies on top of the first 4 patches
> of my "fast mutex rework" series (conflicts in posix only).
> Jan
> PS: gna.org is dead. Hope it will recover soon...

Server has moved. DNS are slowly catching up.


Xenomai-core mailing list

Reply via email to