From alsa-devel-owner@alsa.jcu.cz  Mon Jan 11 15:03:43 1999
Received: from janus.ericsson.no (janus-ext.ericsson.no [193.215.242.105])
	by marvin.jcu.cz (8.9.1a/8.9.1) with ESMTP id PAA21891
	for <alsa-devel@alsa.jcu.cz>; Mon, 11 Jan 1999 15:01:50 +0100
Received: from tele1.eto.ericsson.se (tele1 [193.161.187.12])
	by janus.ericsson.no (8.9.0/8.9.0) with ESMTP id PAA16741;
	Mon, 11 Jan 1999 15:01:36 +0100 (MET)
Received: from tele2 (tele2 [193.161.187.13])
	by tele1.eto.ericsson.se (8.9.0/8.9.0) with SMTP id PAA16054;
	Mon, 11 Jan 1999 15:03:38 +0100 (MET)
Received: by tele2 (5.0/client-1.5 (tele))
	id AA10574; Mon, 11 Jan 1999 15:07:11 +0100
Date: Mon, 11 Jan 1999 15:07:11 +0100
Message-Id: <9901111407.AA10574@tele2>
From: Stephen Thornton <Stephen.John.Thornton@ericsson.no>
To: alsa-devel@alsa.jcu.cz
Cc: Benjamin GOLINVAUX <golinvaux@benjamin.net>
Subject: Linux scheduler issues.
In-Reply-To: <19990111101124Z2631-2281+1905@nic.funet.fi>
References: <199901092046.PAA25489@renoir.op.net>
	<19990111101124Z2631-2281+1905@nic.funet.fi>
Reply-To: alsa-devel@alsa.jcu.cz
Sender: alsa-devel-owner@alsa.jcu.cz
Precedence: list

Perhaps a little discussion of scheduling might help (re mail from
Juhana Sadeharju <kouhia@nic.funet.fi). I am currently working on a
project that is heavily involved with real time operating systems, and
running realtime operating systems on top of other realtime operating
systems for Ericsson (for digital exchange systems), and have been
fooling with this scheduler nonsense for a while now. 

A scheduler can be implemented in several ways, and most schedulers
use a mixture of several possible schemes. The simplest scheduler is
called a round-robin scheduler, and simply cycles through a list of
processes. 

	void (*process_table)()[MAX_PROCESSES];
	void (*)() process_pointer;

	for (process_pointer = process_table; ; pointer++) {
	    if (process_pointer==NULL) 
		/* assume last table entry is NULL */
		process_pointer=process_table;
	    (*(process_pointer))();
        }

There is a problem with this. If one of the processes, crashes, hangs,
or blocks in any way, then nothing happens until it is released, and
the whole system hangs. The next refinement is to add timeslicing.
Basically the idea here is to allocate a maximum amount of time that a
process can run before it must release the processor to the next
process in the list. Unfortunately C is a bad language to express this
easily as we need to have signals and such to do this which are not
part of C. (Natural part of the Erlang language though), but you get
the idea. This scheme too has problems, as we may want to prioritise
some processes, and thus make the scheduler pre-emptive. What this
means is that a high priority process can grab the processor from a
lower priority process, and this is where things can get complicated.
Do we give the higher priority interrupting process just one
timeslice, or let it return? Supposing another process at the same
priority level interrupts, do we make a timeslice algorithm, or use a
round-robin within each priority level, or both? How do we cope with
errors?
	To be more specific about Linux: Blocking mode means that the
thread or process is suspended until something happens (a byte or
buffer is wriiten or read) and other threads can be run according to
the algorithms the scheduler uses. Once the Blocking call completes,
the thread can be run again, whenever the scheduler chooses to run it.
But remember, besides your nice little audio app. there are quite a
lot of system processes that can suddenly preempt at awkward moments,
and no way of knowing what they might do to your delicate audio
timings. Short of re-writing the Scheduler and kernel, there is not a
lot can be done about this.
	KURT and realtime Linux are not ideal solutions either.
Hope this helps a bit.

cheers
Steve

