[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: The Scheduler
> By the way, I would like to see how you would structure a
> changeable scheduler that supports all the features proposed in
> > Further (and relatedly), I'm curious why priority and quantum are
> > defined as the only thread-related data that affect the
> scheduling. If
> > the scheduling algorithm were separate, there might be other data it
> > would want to consider (e.g., deadlines).
> This is an open-ended issue. I'm proposing a basic (but not minimal)
> thread system with features similar to those found in mainstream
> thread systems. In fact the thread system I propose is more powerful
> than most mainstream thread systems (for example few thread systems
> support per thread quantums and absolute timeouts). If there is a
> need for other "non-mainstream" features, such as deadlines, then a
> new SRFI can be proposed. My hope is that it will be a pure extension
> of SRFI-18 (that is why it is important to have a scheduling semantics
> that is not too restrictive).
Maybe I'm just suggesting that 'priority' be made more generic, and that
a partial order of threads be specified. Perhaps specifically, that a
THREAD-PRIORITY>? procedure be defined (which could be redefined by 'the
user'). Of course, this would mean removing the restriction that
thread-priority be an "exact integer (where higher numerical values mean
It may be the case the quantum should be factored into this, as well as
the amount of time a thread has become runnable. I suspect not.
If the THREAD-PRIORITY>? approach were adopted, then the 'fairness
constraints' section remains the same, the 'priority aging' issue goes
away (user x, want to implement priority aging? Just change
THREAD-PRIORITY>? to reflect this), I could implement deadlines, etc.
What do you think? Does this mess up the semantics too much? Make things