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. In a nut shell, the posix skin should be changed to use the new feature instead of implementing its own behaviour. -- Gilles Chanteperdrix. _______________________________________________ Xenomai-core mailing list Xenomaiemail@example.com https://mail.gna.org/listinfo/xenomai-core