RE: The Scheduler Will Fitzgerald 13 Apr 2000 15:27 UTC
> By the way, I would like to see how you would structure a > changeable scheduler that supports all the features proposed in > SRFI-18. > > > 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). > > Marc > > 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 higher priority)." 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 too inefficient?