Applications "buying" resources

Hi,

My RTOS has hooks that let the "kernel" ask tasks
(forget how that is defined) to voluntarily shed
resources (time, memory, power). This lets the
kernel (actually, a "special" user-land task that
makes decisions *for* the kernel) throttle back
the demands placed on the *fixed* resources to
better adjust to the current demands placed on them.

So, if some "new" task needs to be spawned and
needs some resources, the kernel can ask the
currently running set of tasks to relinquish
resources that they may be holding but not *needing*.

But, my current implementation has very coarse
granularity. In essence, the kernel uses increasingly
harsh tactics to get what it needs:
- "please give up resources"
- "you WILL give up resources"
- "if you won't cooperate, you'll have to go away"
- "die, sucker!"

Of course, if all applications were well behaved, they
would comply with early requests and, hopefully, stave
off the more severe requests that could follow.

But, applications tend to "gamble" -- "maybe someone else
will give up enough resources so I won't have to!" This
effectively reduces resource management to:
- "please give up resources"
- "die, sucker!"

I can tweak the resources *available* to a particular task.
But, if I use this mechanism to compensate for "uncooperative"
tasks, then it unnecessarily restricts their capabilities...
which makes them *more* inclined to "not cooperate" (as
they *horde* the limited resources that they have!)

What I would like is a scheme whereby applications can decide
how much the resources they are holding are "worth". And,
then "buy" those resources (with some sort of constrained
"purse"). This gives the "kernel" a bit more flexibility
in handling resource reallocation -- e.g., *it* sets the
current price for the resources and can change that price
dynamically to "entice" tasks to shed resources (by making
it increasingly expensive to hold onto them)

[there are some fairness issues I still need to think through...
e.g., if task A gave up a resource at a pricepoint of K units
and the kernel then raises the pricepoint to L units, should
task A be compensated for his "early sale"?]

Of course, this approach kicks the can down the road a bit
as it now requires me to decide on how much "cash" each
task is given (and if it can vary).

While this seems like a cute idea/model, I wonder if there
isn't a simpler scheme that I could fall back onto?

[remember, my goal is always to NOT have to ask the user
to make these decisions -- especially at the instant the
resource shortage manifests!]

Thanks!
--don
.

Relevant Pages