Re: [Xenomai-core] Pending ownership and resource stealing

[Philippe Gerum <rpm@xenomai.org>]

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()).

-- 

Philippe.