Gilles Chanteperdrix wrote:
Philippe Gerum wrote:
> 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.

When waking up, how do we know that we are in the problematic situation

The only possible issue with the new implementation is when the skin maintains its own specific data for tracking ownership of a resource, that complements the synch::owner field of the core nucleus resource object. The example code Jan has posted lately to raise the concern about the XNBREAK issue is also demonstrative of the issue of pending ownership, i.e.:

prio(task1) > prio(task2)

1. task1 grabs a resource
2. task1 sleeps for some time
3. task2 blocks requesting the resource
4. task1 wakes up from the sleep and releases the resource to task2
5. task1 wants the resource back immediately and calls xnsynch_sleep_on() since the ownership has been transferred to task2 since step 4. 6a. old way: task1 would block and task2 would run anyway, with a PIP boost, blocking task1 until the resource is released 6b. new way: task1 steals the resource previously granted to task2 directly from xnsynch_sleep_on(), but doing so, nobody downstream has had a chance to update any skin-specific data, such as an additional "owner" field.

The caller of xnsynch_sleep_on() in native/mutex.c illustrates this (i.e. grab_mutex label).

 Can we do the house keeping in the callback registered with
xnsynch_register_cleanup, or are you talking of a different situation ?

It's different. The cleanup handler as described by Jan is only there to perform some housekeeping chores on synch objects which get forcibly released because their previous owner went away (typically xnpod_delete()).



Xenomai-core mailing list

Reply via email to