<br><br><div class="gmail_quote">2009/4/29 Michael van der Gulik <span dir="ltr">&lt;<a href="mailto:mikevdg@gmail.com">mikevdg@gmail.com</a>&gt;</span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

<div class="im">On 4/29/09, Eliot Miranda &lt;<a href="mailto:eliot.miranda@gmail.com">eliot.miranda@gmail.com</a>&gt; wrote:<br>
</div><div class="im">&gt; Hi Andreas,<br>
&gt;<br>
&gt; On Tue, Apr 28, 2009 at 8:33 PM, Andreas Raab &lt;<a href="mailto:andreas.raab@gmx.de">andreas.raab@gmx.de</a>&gt; wrote:<br>
<br>
</div><div><div></div><div class="h5">&gt;&gt; This is actually along similar lines of thought that I had when I was<br>
&gt;&gt; thinking of how to get rid of the builtin VM scheduling behavior. The main<br>
&gt;&gt; thought that I had was that the VM may have a &quot;special&quot; process - the<br>
&gt;&gt; scheduler process (duh!) which it runs when it doesn&#39;t know what else to<br>
&gt;&gt; do.<br>
&gt;&gt; The VM would then not directly schedule processes after semaphore signals<br>
&gt;&gt; but rather put them onto a &quot;ready&quot; queue that can be read by the scheduler<br>
&gt;&gt; process and switch to the scheduler process. The scheduler process decides<br>
&gt;&gt; what to run next and resumes the process via a primitive. Whenever an<br>
&gt;&gt; external signal comes in, the VM automatically activates the scheduler<br>
&gt;&gt; process and the scheduler process then decides whether to resume the<br>
&gt;&gt; previously running process or to switch to a different process.<br>
&gt;&gt;<br>
&gt;&gt; In a way this folds the timer process into the scheduler (which makes good<br>
&gt;&gt; sense from my perspective because much of the work in the timer is stuff<br>
&gt;&gt; that could be more effectively take place in the scheduler). The<br>
&gt;&gt; implementation should be relatively straightforward - just add a scheduler<br>
&gt;&gt; process and a ready list to the special objects, and wherever the VM would<br>
&gt;&gt; normally process switch you just switch to the scheduler. Voila, there is<br>
&gt;&gt; your user-manipulable scheduler ;-) And obviously, anything that is run<br>
&gt;&gt; out<br>
&gt;&gt; of the scheduler process is by definition non-interruptable because there<br>
&gt;&gt; is<br>
&gt;&gt; simply nothing to switch to!<br>
&gt;<br>
&gt;<br>
&gt; How would you generalise this to a natively multi-threaded VM?  Obviously<br>
&gt; one simple way is to stop the other processors at a suspension point before<br>
&gt; letting the scheduler process proceed, but is there anything cleverer that<br>
&gt; doesn&#39;t halt all processors until the singleton scheduler has made its mind<br>
&gt; up?<br>
<br>
</div></div>Every OS thread would have it&#39;s own scheduler process. Each scheduler<br>
process has it&#39;s own data structure (collection of process lists in<br>
runlevels / balancing tree / whatever) which it has complete ownership<br>
over meaning that it doesn&#39;t need to synchonise access to it. Each<br>
process has affinity with a particular scheduler so that the<br>
interrupt-like mechanism Igor mentioned would hold only for that<br>
particular scheduler instance and it&#39;s associated list/tree/whatever<br>
of processes.<br>
<br>
Each scheduler process would then communicate with other scheduler<br>
processes using something like... umm... a shared queue of messages<br>
that it would poll on... or something. I haven&#39;t thought out all the<br>
details here yet. The communication would be necessary for (at least:)<br>
<br>
* moving processes between schedulers. This would happen when a<br>
scheduler goes idle so that load balancing happens.<br>
<br>
* signalling semaphores where the waiting process belongs to another scheduler.<br>
<br>
* and other stuff I haven&#39;t thought of yet.<br>
<div><div></div><div class="h5"><br>
Gulik.<br>
<br>
--<br>
<a href="http://gulik.pbwiki.com/" target="_blank">http://gulik.pbwiki.com/</a><br>
<br>
</div></div></blockquote></div><br>Communication between local schedulers could be controlled by special global scheduler on the language side too (load balancing...).