Jan Kiszka wrote:
Besides this, we then may want to consider if introducing a pending
ownership of synch objects is worthwhile to improve efficiency of PIP
users. Not critical, but if it comes at a reasonable price... Will try
to draft something.
I've committed an implementation of this stuff to the trunk, tested on
your testcase over the simulator. So far, it's ok. The only thing that
should change downstream compared to the previous behaviour is that
xnsynch_sleep_on() might unblock immediately at skin level without any
xnsynch_wakeup_sleeper() calls being previously invoked, since the
blocking call does the stealing during the pending ownership window.
This means that skins now _must_ fix their internal state when unblocked
from xnsynch_sleep_on() if they happen to track their own resource owner
field for instance, since they might become the owner of such resource
without any unlock/release/whatever routine being called at the said
skin level. I've fixed a couple of skins for that purpose (not checked
RTDM btw), but it would be safer if you could double-check the impact of
such change on the interfaces you've crafted.
This change only affects PIP-enabled synchronization objects in a
reasonably limited manner and seems to behave properly, but please, give
this code hell on your side too.
Xenomai-core mailing list