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
Description: OpenPGP digital signature
_______________________________________________ Xenomai-core mailing list Xenomaifirstname.lastname@example.org https://mail.gna.org/listinfo/xenomai-core