2009/4/29 Andreas Raab <andreas.raab at gmx.de>:
> Igor Stasenko wrote:
>>
>> I came to an idea , you might be interested in.
>> As many of us know, some CPUs having a special mode - interrupt mode.
>> What if we introduce the interrupt mode for scheduler?
>
> [... snip ...]
>>
>> Now i trying to imagine, how a basic stuff might look like(please
>> correct me if its utterly wrong way ;), if we will be able to use
>> interrupt mode.
>
> This is actually along similar lines of thought that I had when I was
> thinking of how to get rid of the builtin VM scheduling behavior. The main
> thought that I had was that the VM may have a "special" process - the
> scheduler process (duh!) which it runs when it doesn't know what else to do.
> The VM would then not directly schedule processes after semaphore signals
> but rather put them onto a "ready" queue that can be read by the scheduler
> process and switch to the scheduler process. The scheduler process decides
> what to run next and resumes the process via a primitive. Whenever an
> external signal comes in, the VM automatically activates the scheduler
> process and the scheduler process then decides whether to resume the
> previously running process or to switch to a different process.
>
> In a way this folds the timer process into the scheduler (which makes good
> sense from my perspective because much of the work in the timer is stuff
> that could be more effectively take place in the scheduler). The
> implementation should be relatively straightforward - just add a scheduler
> process and a ready list to the special objects, and wherever the VM would
> normally process switch you just switch to the scheduler. Voila, there is
> your user-manipulable scheduler ;-) And obviously, anything that is run out
> of the scheduler process is by definition non-interruptable because there is
> simply nothing to switch to!
>

Very nice indeed. That's even better that my first proposal.
ProcessorScheduler>>schedulingProcessLoop
[
  self handlePendingSignalsAndActions.
  activeProcess ifNil: [ self idle ] ifNotNil: [ self
primitiveTransferControlTo: activeProcess].
]  repeat.

and when any process, somehow stops running
(suspend/wait/terminate/interrupted etc), VM will again switch to
scheduler process loop.

What is important in having it, that there is guarantee to be not
preempted by anything. Simply by having this, many
concurrency/scheduling related problems can be solved by language-side
implementation, without fear of having gotchas from VM side.

Also, VM doesn't needs to know details about priorities, suspending,
etc etc..  - which means that we can simplify VM considerably and
implement same parts on the language side, where everything is late
bound :)

As for moving to multi-cores.. yes, as Gulik suggests, its like adding
a new dimension:
 - local scheduler for each core
 - single global scheduler for freezing everything

This, of course, if we could afford running same object memory over
multiple cores. Handling interpreter/object memory state(s) with
multiple cores is not trivial thing.

If we going to keep more isolated model (islands, hydra ) then we need
no/minimal changes to scheduler - each scheduler serves own island and
receives asynchronous signals from other collegues through shared
queue.

> Cheers,
>  - Andreas
>


-- 
Best regards,
Igor Stasenko AKA sig.