Sat Jan 18 16:07:32 CET 2020

Priority inheritence, opaque tasks

Suppose the highest priority task blocks.  Its events now become high
priority, and anything that can potentiall unlock it should become
high priority.

What we want to do is to solve the transitive problem: there might be
a low priority task that potentially unlocks the high pri one through
a chain of dependencies.  But there doesn't seem to be a way to do

E.g   P1 -> P2 -> P3

Where P3 is high pri, P1 is low pri, and P2' is mid pri.  If it
doesn't know how to promote the chain, it will run P2' first.

This should read like this: P1 can be scheduled, which would unlock
P2, which then performs a write which will unlock P3.

The scheduler cannot see this because tasks are opaque.

There doesn't seem to be a way to promote P1.

Maybe it should be done the other way around: maybe events should have
priorities.  E.g. suppose a high priority write (e.g an interrupt)
unlocks P1, any subsequent actions should be treated as high priority
and executed first.

Maybe it is even enough to make the scheduler greedy?  E.g. suppose an
interrupt creates a hot task.  This is scheduled, possibly unlocking
more.  Those unlocked tasks should be treated as high priority.  But
not all of them would be.
I can't wrap my head around it..