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
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 th
Philippe Gerum wrote:
> Jan Kiszka wrote:
>> Philippe Gerum wrote:
>>> 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,
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 i
Jan Kiszka wrote:
Philippe Gerum wrote:
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'
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
> xnsync
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 unl
Philippe Gerum wrote:
> 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
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 b
