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

[Philippe Gerum <rpm@xenomai.org>]

Gilles Chanteperdrix wrote:
> Philippe Gerum wrote:
>  > Gilles Chanteperdrix wrote:
>  > > Philippe Gerum wrote:
>  > >  > 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.
>  > > 
>  > > Posix skin mutexes work the new way without calling xnsynch_sleep_on, so
>  > > probably need fixing.
>  > > 
>  > 
>  > I don't see any additional information maintained by the skin, aside of 
>  > the sem->count field, so that should be ok as it is. Is there anything 
>  > else recorded for tracking the current ownership of a sem-mutex object?
> 
> The mutex->count field is unconditionnaly set to 0 and task2 woken up
> when task1 releases the mutex, so that when task1 want the mutex again,
> it will appear as free, and task1 will get it without calling
> xnsynch_sleep_on, task2 will eventually wakeup spuriously or not
> depending on whether the mutex is free. So, setting the count to 0 when
> waking up seems wrong.
>

We just need to set it to 1 instead, just like if we were returning from
mutex_trylock_internal() successfully.

> In a nut shell, the posix skin should be changed to use the new feature
> instead of implementing its own behaviour.
> 

There is no new feature per se, just an additional case upon return from
xnsynch_sleep_on() to take into account.

-- 

Philippe.