Article View: shlink.atari
Article #3Re: c't ueber den Falcon 030
From: Christoph Weber-Fahr [KIT]
Date: Wed, 22 Jul 1992 13:52
Date: Wed, 22 Jul 1992 13:52
97 lines
5178 bytes
5178 bytes
Hallo,
barnard@forge.erh.sub.org (Henning Schmiedehausen) writes:
>Thomas Schulze [TfS] writes:
>>Hallo,
>>barnard@forge.erh.sub.org (Henning Schmiedehausen) writes:
>>> Chris Vetter writes:
>>>
>>>>> 'Der Falcon wird echtes Multitasking ueber Zeitscheiben
>>>>> beherrschen; dafuer sorgt MultiTOS im Zusammenspiel mit der
>>>>> MMU. Weiterhin enthaelt der Rechner einen schnellen, auch von
>>>>> aussen zugaenglichen Signalprozessor, den auch
>>>>> im NeXT eingesetzten Motorola DSP 56001.'
>>>>
>>>> Das ist allerdings was feines.
>>>
>>> Wenn das 'nur' ein Zeitscheiben-Multitasking ist, dann hast Du
>>> das gleiche, wie unter WinDoof. Es sollte schon ein echtes,
>>> eventgesteuertes Multitasking
>>> sein.
>>
>> Haeh?? Also, mir ist Zeitscheiben-Multitasking lieber. Event-
>> gesteuert ist doch genau das, was Windows oder das aktuelle
>> TOS/AES oder der Mac so betreiben, Zeitscheiben werden zB unter
>> *ix, os9 oder (!) MiNT verwendet...
>Nein. Zeitscheiben-Multitasking ist, wenn jeder Prozess xx ms zum rechnen
>bekommt und danach der naechste drankommt. Was der Prozess macht (z.B.
>Busy-Waiting) ist dem Scheduler voellig egal. D.H. je mehr Prozesse, desto
>langsamer die CPU. Das machen WinDoof und der Multifinder. Fuer TOS/AES und
>MiNT hoffe ich, dass sie das nicht machen ==:)
Oh Henning, bitte nicht schlagen, aber das ist einfach Schwachsinn.
Du vermischst hier I/O- und Multitasking-Konzepte.
a.) I/O kann Eventgesteuert oder nicht sein. Ein Multitasking-BS kann die
Event-Aufrufe (genau wie andere Aufrufe) fuer Prozesswechsel nutzen,
ganz egal, ob es Zeitscheiben- oder nicht Zeitscheiben-gesteuert ist.
b.) Multitasking-Systeme sind
- preemptiv: Das BS entscheidet selbstaendig, ob und wann ein Prozess-
wechsel stattfindet. Der Prozess bekommt davon gar nichts mit.
- nicht preemptiv: Prozesse koennen die Kontrolle nur freiwillig abgeben.
c.) Ausserdem unterscheidet man Scheduling-Strategien, d.h. Strategien, nach
denen entschieden ird, welcher rechenwillige Prozess bei einem Prozess-
wechsel aktiviert wird. Es gibt hier u.a.
- Round Robin (alle reihrum)
- Priority Scheduling (das nennst Du hier Zeitscheiben-Steuerung),
ein Prioritaetsmodifiziertes Round-Robin-Verfahren
- Multiple-Queue-Verfahren (Priority-Scheduling modifiziert fuer optimale
Auslastung von IO und Revchenintensiven Prozessen)
- Guranteed Scheduling (fuer Echtzeit-Systeme)
- Two-Level-Scheduling
u.v.m.
Im Prinzip kannst Du nun alle Multi-Tasking-Konzepete mit allen I/O
und Scheduling-Konzepten kombinieren, obwohl bestimmte Kombinationen
sinnlos oder auch unmoeglich sind.
Der Mac hat z.B. Event-Getriebenes I/O, nicht-preemptives Multitasking.
(Frag mich nicht nach Scheduling, ich vermute die machen Round-Robin)
Ueber Windows sag ich nichts, da hab ich zu wenig Details.
>Event-gesteuert, heisst, alle Prozesse bekommen zwar auch eine Zeitscheibe,
>aber wenn er z.B. auf eine Tastatur-Eingabe wartet, dann wird er schlafen
>gelegt, bis (*das Event* :) ) die Taste gedrueckt wird. In der Zwischenzeit
>koennen andere Prozesse die CPU nutzen. D.H. Prozesse, die auf ein Ereignis
>warten, brauchen *keine* Rechenzeit.
Das ist alles schoen und richtig, hat aber mit Event-Steuerung nichts zu tun,
das ist einfach zeitgemaesses I/O.
I/O-Streams von Unix machen das ganz genauso. Ich geb Dir ja recht, dass
I/O via polling nicht mehr dem Stand der Technik entspricht, aber es gibt
kein Betriebssystem der Welt, das verhindern kann, dass eine Anwendung
sinnlose Warteschleifen ausfuehrt. Das ist auch das Problem wit DOS-
Anwendungen unter OS/2 oder WIN-DOOF. Wenn die Warteschleifen haben,
dann ist das eben so. Punkt.
>> Hast Dich wohl vertan??!! :-))
>Sicher nicht. Ich habe einen Amiga, da *weiss* man, was Event-driven
>Multitasking ist. (ausserdem studiere ich noch ein bischen Informatik =:)
Also bevor du in die BS-Pruefung gehst, solltest Du diesen Komplex noch ein
wenig vertiefen :-)
BTW - ein guter Schmoeker zum Thema ist Tanenbaum's "Modern Operating
Systems", Prentice-Hall, Englewood Clifffs 1992
Gruss
Christoph Weber-Fahr
--
Christoph Weber-Fahr | E-Mail: weber@rhrk.uni-kl.de
Universitaet Kaiserslautern, KIT | S-Mail: Postfach 3049
Tel. 0631/205-3391 | D-6750 Kaiserslautern
-------------------------- My personal opinion only ---------------------
Technical Details
Message-ID:
<1992Jul22.135252.26167@rhrk.uni-kl.de>Path:
arc1-ca.pugleaf.net!sparky!uunet!wupost!sdd.hp.com!mips!darwin.sura.net!jvnc.net!yale.edu!ira.uka.de!rz.uni-karlsruhe.de!stepsun.uni-kl.de!sun.rhrk.uni-kl.de!weberReferences:
<1111151@shlink.hanse.de> <1992Jul17.101847.18858@infoserver.th-darmstadt.de> <K37nr*vg0@forge.erh.sub.org> <1992Jul20.143856@uni-paderborn.de> <QE1or*Cg0@forge.erh.sub.org>Show Full Headers
Complete Article Headers
Newsgroups: shlink.atari,de.comp.sys.st Path: arc1-ca.pugleaf.net!sparky!uunet!wupost!sdd.hp.com!mips!darwin.sura.net!jvnc.net!yale.edu!ira.uka.de!rz.uni-karlsruhe.de!stepsun.uni-kl.de!sun.rhrk.uni-kl.de!weber From: weber@rhrk.uni-kl.de (Christoph Weber-Fahr [KIT]) Subject: Re: c't ueber den Falcon 030 Message-ID: <1992Jul22.135252.26167@rhrk.uni-kl.de> Organization: University of Kaiserslautern, Germany References: <1111151@shlink.hanse.de> <1992Jul17.101847.18858@infoserver.th-darmstadt.de> <K37nr*vg0@forge.erh.sub.org> <1992Jul20.143856@uni-paderborn.de> <QE1or*Cg0@forge.erh.sub.org> Date: Wed, 22 Jul 1992 13:52:52 GMT Lines: 97