Newsgroup: it.comp.os.dibattiti
Titolo: Multitasking in Windows, Multitasking in AmigaOS

Poco tempo fa sul newsgroup "it.comp.os.amiga", grazie al post di qualcuno
che non c'entra niente con tale newgroup, c'e' stata una violenta polemica
su [vedi oggetto]. In questo mio post faro', per quanto mi e' possibile,
chiarezza sull'argomento, esponendo le cose che ho letto e verificato
personalmente:
1. In tali messaggi si diceva: "Il multitasking di Amiga e' vero
multitasking, quello di Windows non e' vero multitasking". Questa
espressione ha del vero, ma deve essere piu' precisa:
  1.1 AmigaOS ha un vero multitasking: ogni volta che eseguo un programma da
Workbench, o da shell (con il comando "run >NIL: nomefile") viene creato un
nuovo processo, indipendente dagli altri. Questo lo si puo' sperimentare:
sotto shell avviate (in background, col comando "RUN >NIL: nomefile") due
task, ad esempio un'applicazione grafica ed una che suona un MOD in
sottofondo; ad un certo punto fate in modo (o immaginate: questa situazione
e' capitata sicuramente a tutti) che l'applicazione grafica vada in crash:
prima di dare lo schermo rosso-nero dell'amigo GURU, viene visualizzata una
SystemRequest (che solo alla pressione del bottone "Cancel" dara' il via al
GURU): se la lasciamo li dov'e' ignorandola, continueremo ad ascoltare il
nostro file MOD in tutta tranquillita' e non solo: potremo avviare qualsiasi
altra applicazione essendo sicuri che questa funzionera'. Ovviamente
l'applicazione "crashata" assorbira' risorse al sistema, che quindi non
sara' in una situazione di stabilita', questo pero' non impedisce l'avvio ed
il funzionamento delle altre applicazioni.
  1.2 Sotto Windows 9x/ME le cose non stanno cosi': tutte le applicazioni
Windows costituiscono un unico task, mentre ciascuna finestra "Prompt di
MS-DOS" costituisce un task a parte (Fonte: Programmare in Visual Basic 4,
di Gerard Frantz). Eccone la prova: provate a formattare un dischetto da
Windows (con tasto destro, "Formatta..." ecc) ed a fare qualsiasi altra cosa
(es. ascoltate un MP3). Noterete un certo rallentamento. Ora ripetete
l'esperimento eseguendo pero' la formattazione da una finestra del prompt di
ms-dos, col comando "format a: /u" o simili; contemporaneamente ascoltate
l'mp3. Non noterete alcun degrado sensibile di prestazioni.
  1.3 Sotto Windows NT/2000 e quindi (immagino) anche sotto XP (che deriva
dalla tecnologia NT), c'e' un vero multitasking: ogni appplicazione aperta
costituisce un task a parte. Ecco perche' una certa persona diceva di non
notare rallentamenti di sorta quando formattava un dischetto.
2. Sempre su ICOA, si parlava di Bill Gates e della sua possibilità di
appropriarsi del codice sorgente di AmigaOS e di usarne il vero
multitasking. Si diceva: "certamente non gli mancano le risorse". Ma
riflettete un attimo: cosa glienefrega a Bill Gates di copiare il vero
multitasking di Amiga? Certo che le risorse non gli mancano, ma cosa gli
puo' importare di Amiga?

 puo' importare di Amiga?
E poi si sa che hanno gia' copiato tutto da Linux, no?
-- 
disclaimer: not speaking for anybody but me.

 puo' importare di Amiga?
Appunto, ed infatti nessuno ne ha parlato... cosa fumi? Sol per
curiosita'...
Fabio Alemagna

 puo' importare di Amiga?
Appunto... :-)
Marco

 E poi si sa che hanno gia' copiato tutto da Linux, no?
Veramente il multitask di NT4 ha molto di simile (ma anche molto di dissimile)
dallo XENIX che la stessa Microsoft ha sviluppato per un paio d'anni.
Da qualche parte dovranno pur aver cominciato, no? :-)
Marco

 quando gli accessi a tali risorse si accodano o competono per tempo CPU.
Magari dico una cazzata... :-))
Ma oltre a come il SO gestisce i threads ed i tasks forse c'e' anche da
considerare l'efficenza con cui vengono gestite, a piu' basso livello
HW, le IRQ e l'efficenza dei drivers che gestiscono le DMA (il FDD credo
usi il 2° canale come riservato) magari e' anche qui' che i sistemi Win
(almeno fino al 98) sono deboli. Un conto e' gestire semplicemente dei
processi un'altro e' gestire processi che fanno frequenti richieste alle
periferiche (FDD, HDD, COM, USB ecc.) in modo concorrente. Un casino...
-- 
_______________
Alessandro
--------------------------

 wrote in message news:3B7D1C...@texnet.it...


In parte quello che ho scritto afferma (velatamente) questo. La scelta di operare alcuni
boost di proprietà su base casuale, in operazioni non continue e frequenti come gli accessi
al floppy o alle porte di I/O, potrebbe non comportare vantaggi evidenti e potrebbe rivelarsi
addirittura controproducente in certi casi. D'altro canto, per poter affermare con esattezza
una cosa simile, dovremmo disporre di informazioni più dettagliate sui timing e sui cicli di
scansione fissi... non sempre la randomicità è deleteria: MOSIX (un "hack" del kernel di Linux
volto alla costituzione di cluster di potenza di tipo NOW), ad esempio, fa un ampio uso di
funzioni di assegnamento di CPU e memoria puramente randomiche (almeno nella prima fase
di iniezione dei processi nel cluster), con performance molto spesso stupefacenti (soprattutto
se paragonate alla gestione della memoria disponibile operata dal più blasonato beowulf).
Per il resto, non credo che ci siano driver inefficienti per i lettori di floppy disk... diciamo
che ormai c'è una consolidata e storica letteratura in materia :-)))
Certamente, se dev'esserci arbitraggio a basso livello per l'accesso alle risorse, può darsi che
al FDD sia stato assegnato nel tempo un livello di priorità di default decisamente più basso
(correttamente... visto che HD, CD, CDRW e adesso DVD la fanno da padroni...).
Marco

 (correttamente... visto che HD, CD, CDRW e adesso DVD la fanno da padroni...).
Un paio di cose.
Innanzi tutto l'architettura PC facila molto le cose, avendo
un gran spreco di risorse.
Mi spiego: il fatto che gli x86 abbiano 15 linee di interrupt e,
fino a qualche tempo fa, ogni periferica avesse una sua linea
propria, senza condivisione, consente di scrivere in maniera
molto piu` semplice l'OS.
Infatti ad ogni interrupt si assegna il suo specifico driver
ed e` finita. Idem per i canali DMA.
Un pelo piu` complicato e` condividere queste risorse
Nel suddetto caso floppy, ad es., l'interrupt ed il DMA potrebbero
benissimo essere usati da altri, dato che il floppy non e` usato
spessissimo, con ovvia complicazione del SW.
Un ottimo esempio di condivisione di risorse (irq & DMA) e`
(od era?) AmigaOS, con un design realmente all'avanguardia.
Il problema in un PC e` _solo_ assegnare le giuste
priorita` (con tutti i limiti del caso, vedi irqtune docs)
alle varie risorse HW.
Seconda cosa: di solito sarebbe bene assegnare piu` alta
priorita` alle perifichere che:
1) non possono aspettare (ad es. seriale)
2) quelle che usano meno la risorsa.
Nel caso del floppy, essendo usato poco, converrebbe dargli
priorita` elevata e non bassa (cosi` si leva dalle scatole
ancora piu` rapidamente...).
bye,
-- 
  Piergiorgio Sartor

 ancora piu` rapidamente...).
Sto cercando di capirci qualcosa e perl'appunto ho sottomano l' OS/2:
dando un'occhiatina alle risorse HW con il comando RMVIEW
scopro che non c'e' una risorsa che sia shared, o sono exclusive oppure
multiplexed:
[F:\]rmview /irq
RMVIEW: Physical view
  IRQ Level =  0  PCI Pin = NONE  Flg = EXCLUSIVE    TIMER_CH_0
  IRQ Level =  1  PCI Pin = NONE  Flg = EXCLUSIVE    KBD_0 Keyboard
Controller
  IRQ Level =  2  PCI Pin = NONE  Flg = EXCLUSIVE    PIC_1
  IRQ Level =  4  PCI Pin = NONE  Flg = MULTIPLEXED  SERIAL_0 Serial
Controller
  IRQ Level =  5  PCI Pin = NONE  Flg = MULTIPLEXED  Crystal Business
Audio
  IRQ Level =  6  PCI Pin = NONE  Flg = MULTIPLEXED  FLOPPY_0 Floppy
Controller
  IRQ Level =  7  PCI Pin = NONE  Flg = MULTIPLEXED  PARALLEL_0 Parallel
Control
ler
  IRQ Level =  8  PCI Pin = NONE  Flg = EXCLUSIVE    RTC
  IRQ Level = 12  PCI Pin = NONE  Flg = EXCLUSIVE    AUX_0 PS/2
Auxiliary Device
 Controller
  IRQ Level = 14  PCI Pin = NONE  Flg = MULTIPLEXED  IDE_0 (E)IDE
Controller
  IRQ Level = 15  PCI Pin = NONE  Flg = MULTIPLEXED  IDE_1 (E)IDE
Controller
[F:\]rmview /dma
RMVIEW: Physical view
  DMA Channel =  0  Flg =  MULTIPLEXED Crystal Business Audio
  DMA Channel =  1  Flg =  MULTIPLEXED Crystal Business Audio
  DMA Channel =  2  Flg =  MULTIPLEXED FLOPPY_0 Floppy Controller
  DMA Channel =  4  Flg =  EXCLUSIVE   DMA_CTLR_1
 
Suppongo che sia differente "condivisa" da "multiplexata" ...
Vale a dire che un canale multiplexed puo' essere usato
contemporaneamente e non assegnato in tempi diversi?
-- 
_______________
Alessandro
--------------------------

 ancora piu` rapidamente...).
Purtroppo non è così... Ad ogni modo l'ereditarietà della priorità
fornita dallo scheduler secondario di Windows mira proprio ad
ottenere qualcosa di simile, associando dinamicamente ai thread
che richiedono I/O su periferiche "bloccanti" una priorità pari a quella
del thread concorrente a più alta priorità. In ogni altro caso l'impressione
sarebbe quella di una macchina che si siede decisamente quando si
formatta un floppy.
Marco

 contemporaneamente e non assegnato in tempi diversi?
Forse, per il floppy, si intende multiplexato nel caso
vi sia piu` di un floppy drive.
Se hai due drive il DMA _deve_ essere multiplexato
tra i due floppy.
D'altronde non vedo risorse condivise, cioe` DMA 6 (ad es.)
e` multiplexato, ma assegnato al floppy solamente...
bye,
-- 
  Piergiorgio Sartor