🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: shlink.atari
Article #3

Re: c't ueber den Falcon 030

#3
From: Christoph Weber-Fahr [KIT]
Date: Wed, 22 Jul 1992 13:52
97 lines
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!weber
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>

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