linux-l: Multitasking-Konzepte

[Stefan Janke]

Thomas Bange <bange at uni-paderborn.de> writes:

> Das ist falsch. Linux benutzt preemtives Multitasking. Kooperatives
> Multitasking wird z.B. von Win 3.x und MacOS verwendet (das neue kann
> wohl auch preemtives). Der Unterschied ist, das bei kooperativem
> Multitasking die laufenden Programme dafuer verantwortlich sind, das
> auch mal jemand anderes Rechenzeit bekommt. Ich kann also ein Programm
> schreiben, das einfach den Prozessor nicht mehr freigibt und so kein
> anderes Programm mehr zum Zuge kommt. Beim preemtiven Multitasking wird
> das ganze vom Betriebssystemkern verwaltet. Dafuer gibt es dann
> verscheidene Strategien, z.B. RoundRobin. Dabei wird jedes Prog. fuer
> eine bestimmte Zeitdauer ausgefuehr, dannach wird ihm der Prozessor
> "entzogen" und ein anderes Programm ist an der Reihe. Das geht dann
> immer reihum. Jedes Programm wird immer nur ein Stueckchen lang
> ausgefuehrt.  

Ganz kurz gesagt, bei kooprative Multitasking ist man auf die
Mitwrikung der Programm angewiessen, damit die funktioniert (die
Programme muessen sich halt koopeerativ verhalten), aber das
Scheduling wird trotzdem vom Kernel gemacht, aber kann durch diesen
nicht ausgeloest werden. Bei preemptiven (unterbrechendem)
Multitasking wird das Scheduling aber nicht nur durch die
Benutzerprogramme ausgeloest, in diesem Fall kann der Kernel die
Benutzerprogramme unterbrechen und die CPU neu verteilen. Meist wird
dies ueber den Timerinterrupt gemacht.

> Bei preemtiven Multitasking kann das System nicht haengen
> bleiben wie beim kooperativen Multitasking, da das Programm das ganze
> nicht beeinflussen kann.

Naja, natuerlich koennen auch Systeme mit preemptiven Multitasking
haengen bleiben :). Und die Programme koennen dies sehr wohl
beeinflussen , siehe nur mal man sched_setscheduler:
       sched_setscheduler sets both the scheduling policy and the
       associated parameters for the process identified  by  pid.
       If  pid  equals zero, the scheduler of the calling process
       will be set. The interpretation of the parameter p depends
       on  the  selected  policy.  Currently, the following three
       scheduling policies are supported under Linux: SCHED_FIFO,
       SCHED_RR,  and  SCHED_OTHER; their respective semantics is
       described below.
Man kann sich also die Schulingpolitik aussuchen. Daneben kann dies
der Porzess auch durch sched_setparam(2), sched_yield(2), nice(2) und
setpriority(2) beeinflussen. Und mit Echtzeitsystemen geht das ganze
sogar soweit, das man eine hochprioriren Prozess schaffen kann, der
nicht durch den Interrupts verdraengt werden kann (auf jeden Fall
unter QNX und wohl auch mit Real-Time-Linux).

ciao stefan

-- 
Q:	What do little WASPs want to be when they grow up?
A:	The very best person they can possibly be.