[Barrelfish-users] Proposal: separate thread scheduling policy
zchothia at student.ethz.ch
Wed Apr 3 17:22:16 CEST 2013
Context: the threads package implements a hard-coded policy for selecting the
next runnable thread and this logic is spread over several functions.
(Current default is round-robin with uniform priorities.)
Objective: consolidate this in a single function and implement an interface so
applications can easily implement their own policy.
* I initially thought this interface would serve two distinct aspects:
1. Receive notification of interesting events (e.g. thread created/blocked,
something now eligible to run, ...)
2. Whenever necessary, select the next thread to run (new time slice, yield).
In reality though, dispatch occurs immediately in response to an event so the
separation isn't quite as clear.
* Attached is an initial patch which enables an application to override
scheduling decisions - for example, I tried co-operative multitasking.
- Downside: application now depends on threading internals <threads_priv.h>.
- Reason parameter is not of much use on its own; perhaps a payload should
also be passed (thread that yielded, duration of new time-slice).
* Windows 7 has User-Mode Scheduling (UMS) [1, 2] which implements a similar
mechanism and makes for an interesting comparison. It is used in the
implementation of their Concurrency Runtime (ConcRT).
I am interested in any feedback, especially regarding other use cases for
application-level schedulers and what would be required from such an interface.
Conclusion: this change will allow applications to implement their own
scheduling policy without having to duplicate the threads package.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7661 bytes
Url : https://lists.inf.ethz.ch/pipermail/barrelfish-users/attachments/20130403/e402ae94/attachment-0001.obj
More information about the Barrelfish-users