Newsgroup: it.comp.os.dibattiti
Titolo: [Forse OT] Multitasking

Vorrei chiedere ai conoscitori dei Windows Server se č vero che NT/2000
č Multitasking.
Per me č una solenne vaccata ma, non conoscendo adeguatamente i due os
sopracitati, mi affido a chi ne sa piů di me.
Illuminatemi per favore.
Grazie
Nicholas

Mamma mia. Definisci multitasking ed avrai una risposta sensata.
Saluti
Massimo


 è Multitasking.
Si lo sono.
bye,
-- 
  Piergiorgio Sartor

 Nicholas
Ciao, Davide :)

è Multitasking.
Se per multitasking intendi la capacità di un SO di far girare più
applicazioni contemporaneamente, allora si
--
Rhymes (
rhy...@myself.com
)
Brainbench Certification:
Language: Java 1, Score: 3.29, Date: 2001-10-02 
http://www.brainbench.com/transcript.jsp?pid=2435730

 applicazioni contemporaneamente, allora si
Perche' esistono anche altri significati?
Ciao, Davide :)

Perche' esistono anche altri significati?
beh magari Nicholas ne ha un altro da proporci


 multitasking e quindi scatenare l'ennesimo flame....bhe...lasciamo stare
Se leggevi il mio post capivi il significato.
Non conosco Windows a sufficienza (non lo uso a casa, non lo uso a
lavoro, quanto è *ovvio* ora ?) per saperlo e chiedevo a chi ne sa più di me 
su quell'OS.
delucidazioni nell'unico punto di incontro che ho con utenti MS.
So come funziona sulla mia macchina e mi sto guardando la preemptive patch che 
è già inclusa nei kernel 2.5.x, ho fatto una semplicissima domanda per
sapere se e come funziona sotto Windows.
Se vuoi etichettarmi come troll fa pure, certo bastava non rispondere.
Se vedi in una domanda un'accusa la colpa non è certo mia.
Se sei tu a cercare l'ennesimo flame punta su altri cavalli, io non
rendo molto come troll, mi limito a dire cazzate.
Addio.

 Mamma mia. Definisci multitasking ed avrai una risposta sensata.
 
Malposta: riformulo.
Presumo Windows gestisca più processi contemporaneamente.
In che modo e quanto è efficiente ? (parlo solo di w2k e NT, mi sembra
chiaro che non li conosco ... )
Nicholas

Chidevo solo -->> delucidazioni nell'unico punto di incontro che ho con 
utenti MS.
Sono molto rincoglionito oggi: scusate :D

 In che modo e quanto è efficiente ? (parlo solo di w2k e NT, mi sembra
Che vuol dire "efficiente", nel contesto della
gestione di piu` processi?
bye,
-- 
  Piergiorgio Sartor

 gestione di piu` processi?
Ad esempio i task eseguiti dal mio kernel vengono eseguiti finchč non si
fermano (ma va? :DDD). Questa interpretazione č "efficiente" fino a un
certo punto: un'altro task non puň andare in esecuzione finchč quello
precedente non ha finito.
Ora: la patch dei kernel nuovi dovrebbe comportarsi diversamente ma
francamente non č che ho capito benissimo come... sto appunto cercando
documentazione "umana".
Facciamo cosě: tolgo efficiente e, dato che ho appurato che č
multitasking, chiedo: come funziona ?
Madonna ragazzi che fatica perň ....

 multitasking, chiedo: come funziona ?
Eeeeeh, ti pare semplice...
bye,
-- 
  Piergiorgio Sartor

 Eeeeeh, ti pare semplice...
E vabbč... me li andrň a cercare, amen :/
Ciao !

 Addio.
Se ti ho risposto e' perche' ero convinto che nel tuo post ci fosse solo un
po' di confusione.
Ciao, Davide :)

 ha scritto nel messaggio
news:yCXY8.47280$7N3.1...@twister2.libero.it...

Windows , cosi' come linux, utilizza un multitasking di tipo preemptive a
time sharing con la possibilita' di definire delle priorita'.
In poche parole il so assegna ad ogni task in esecuzione un quanto di tempo
permettendogli di utilizzare la cpu solo per quel periodo.
Una volta finito il tempo a disposizione il so sospande il processo e ne
mette in esecuzione un altro fino a quando questo non finisce il suo quanto
di tempo e cosi' via.....
Ovviamente la scelta di quale processo mettere in esecuzione va fatta in
maniera attenta al fine di non sospendere troppo a lungo alcuni processi
(fenomeno della starvation).
Ai processi e' anche associata una priorita' in modo che processi *piu'
importanti* possano avere quanti di tempo maggiori e/o essere messi in
esecuzione piu' spesso.
Spero di avere chiarito qualche tuo dubbio.
Ciao, Davide :)

 Lo so anch'io che il post non era chiaro, puņ capitare no ?
Certo puo' capitare.
Ti ripeto che non era mia intenzione offenderti e, se cio' e' accaduto, ti
chiedo pubblicamente scusa.
Ciao, Davide :)

 [cut]
Allora chiedi spiegazioni come hanno giustamente fatto gli altri, non 
pensare automaticamente che una persona che fa una domanda voglia fare
un flame.
Lo so anch'io che il post non era chiaro, può capitare no ?

 Spero di avere chiarito qualche tuo dubbio.
L'hai fatto: grazie.

 sia più importante ?
Diciamo che tu hai N task nel tuo sistema,
diciamo anche che non ci interessano le
priorita` e aggiungiamo pure che tutti questi
task sono CPU bounded, cioe` non fanno mai
I/O od altre chiamate al SO: usano solo e sempre
la CPU.
In queste ipotesi ogni task ha un certo tempo,
diciamo 1/60 di secondo, dopo di che viene
rimosso a calci nel sedere e si passa al secondo
task, il quale avra` a sua volta un altro 1/60
di secondo, e cosi` via fino ad esaurire gli N
task, dopo di che... Si ricomincia da dove si
era lasciato il primo.
La faccenda e` ovviamente un pelo piu` complicata,
per prima cosa i vari task possono avere diverse
priorita`, quindi la scelta del successivo
dipendera` da questo, secondariamente le priorita`
sono, in Unix, dinamiche, cioe` cambiano per conto
loro a seconda del comportamento del task.
Terzo i task non sono quasi mai CPU bounded, spesso
fanno I/O, in attesa, un'altro task puo` essere
lanciato, e cosi` via...
bye,
-- 
piergiorgio

 è Multitasking.
Si.

chiaro che non li conosco ... )
La domanda cambia completamente :)
Non so cosa tu intenda per "efficienza" di un ambiente multitasking ma
come tu ben sai il multitasking non è _reale_


 chiaro che non li conosco ... )
Distribuendo il tempo di esecuzione ai vari processi in base alle priorità.
L'efficienza da questo punto di vista non è "ottimale" semmai 
"ottimizzata". Un sistema non grafico, senza il ciclo dei messaggi, è 
sicuramente più efficiente ma non è capace di interazione utente.

 come tu ben sai il multitasking non è _reale_
Si, fin li ci arrivo :p
Il primo post l'ho scritto in trance da smanettamento.

 Si.
Salve a tutti, visto che ci siamo approfitto per salutare e per fare
anch'io una domanda a proposito del multitasking.
Ho notato che le attuali implementazioni funzionano tutte benino (parlo
di Linux, Aix, Solaris e Win2k) pero' tutte hanno un punto a mio modo di
vedere molto 'debole': " le sezioni critiche non interrompibili ", alle
volte danno molto fastidio.
Per esempio con linux e solaris se un disposito I/O ad accesso sincrono
'tarda' a rispondere il processo viene tenuto nel run set nello stato
'D', piu' o meno la stessa cosa accade con AIX e con Win2k (anche se con
MS non ho ben capito cosa accade visto che le stranezze sembrano
diverse). Se c'e' un problema anche banale su un sistema di I/0 (caso
non raro se i server sono attestati su una SAN) i processi in sezione
critica " D " diventano moltissimi e succedono grossi casini (Win2k e
linux dopo un po' s'impallano), AIX difficilmente crasha ma e' molto
difficile riprenderne il controllo senza riavviare. La domanda e':
Non e' possibile escludere dallo scheduler un processo in sezione
critica (diciamo semplicemente metterlo in sleep o killarlo) ? esiste,
almeno su linux, qualcuno che si e' divertito sull'argomento e ha
sperimentato qualcosa ?
Ciao a tutti
--
Baldassarra Antonio

 rimosso a calci nel sedere e si passa al secondo
Anche quando sono nel kernel? Per come l'ho capita io, la patch serve 
proprio per rendere il kernel rientrante. Ma forse ho capito male ed il 
problema è diverso.

 flame....bhe...lasciamo stare 
a qualcuno interessano un paio di storie d'orrore sul multitasking in 
Solaris e Linux? fresche fresche, risalenti a ieri pomeriggio
-- 
 < 
http://www.reactos.com/
 >  Open source clone of Windows NT. Current
     Don't stand, REACT!      version 0.0.19. C, C++ and ASM developers
                              and beta testers are welcome!

 problema č diverso.
Per i kernel thread, direi, non per i
processi user.
Cioe` il quando codice kernel viene eseguito,
e` possibile avere comunque preemption, cioe`
si puo` eseguire altro codice.
Il che, detto cosi`, e` un stupidata, spero
solo che sia un tantino diversa la situazione...
bye,
-- 
piergiorgio

 Solaris e Linux? fresche fresche, risalenti a ieri pomeriggio
A me piacciono le storie d'orrore,
raccontami un po'...
bye,
-- 
piergiorgio


Sicuramente il codice del kernel e' del codice particolarmente delicato ma
questo non significa che non sia interrompibile.
L'importante e' che il codice sia stato scritto bene e che le interruzioni
avvengano non in un punto qualsiasi ma solamente in determinati punti.
Ciao, Davide :)

 Solaris e Linux? fresche fresche, risalenti a ieri pomeriggio
e chi se le perde? :)

 questo non significa che non sia interrompibile.
Dovrebbe essere tale da non rendere necessaria
l'interrompibilita`.
Cioe` il codice kernel dovrebbe essere talmente
piccolo e veloce, da non farsi neanche sentire.
Se si deve renderlo interrompibile, secondo me
c'e` qualcosa che non va.
A meno che non vi sia altro, ovviamente.
bye,
-- 
piergiorgio


Il progetto del kernel di un SO va fatto cercando di ottenere proprio cio'
che tu dici e cioe' il *minimo overhead* possibile.
Ci sono comunque delle operazioni che spettano al kernel e che non possono
essere eseguite in tempi brevi (pensa alla gestione della memoria virtuale);
in tal caso e' necessario prevedere dei punti in cui il kernel si possa
sospendere e mettere in esecuzione altri task.
Ciao, Davide :)

 Il kernel e` in grado di eseguire thread.
Su questa parte ho bisogno di delucidazioni.
Io ero rimasto a quando il kernel di linux (e unix) gestiva solamente i task
e la gestione dei thread era lasciata a package esterni. La situazione e'
cambiata?
Ciao, Davide :)

 cambiata?
Ci sono _pezzi_ di kernel che girano
come thread.
bye,
-- 
piergiorgio

 sospendere e mettere in esecuzione altri task.
Oppure rivedere un po' le cose, ad es. passando
la gestione in user space.
O magari gestendo il kernel in modo cooperative,
ma non preemptive.
bye,
-- 
piergiorgio


Il modo cooperativo puo' risolvere dei problemi ma ne puo' inserire altri.
Un buon kernel usa sicuramente entrambi gli approcci in modo da ottenere i
benefici di entrambi; tra l'altro mi sembra di ricordare (non vorrei dire
una cavolata) che windows NT e soci usino un approccio del genere (e
probabilmente lo usano anche linux/unix ).
Ciao, Davide :)

 diversa la situazione...
chiariamo un po' le cose, vedo sempre un sacco di confusione riguardo a 
questo argomento. Ad esempio quando dico che il kernel di Windows NT è 
multithreading, c'è sempre qualcuno che casca dalle nuvole e mi chiede 
"ma che scheduler li gestisce?". Ora che finalmente ci sono arrivata, 
ve lo spiego io. Cosa significa esattamente "kernel mode"? In generale 
che tutti, o molti limiti vengono rimossi. Cosa significa codice non 
interrompibile? in parole povere che il timer interrupt è disattivato 
per la CPU su cui il thread in questione sta girando. Ora, il kernel 
mode implica "codice non interrompibile"? no, non mi pare. "Codice non 
interrompibile" richiede il kernel mode? ovviamente sì. Perchè? ragioni 
di sicurezza, ovviamente. Soprattutto, come? semplice: in kernel mode 
la maschera degli interrupt (il registro che decide quali interrupt è 
possibile ricevere e quali no) è scrivibile, in altre modalità non si 
può toccare. Generalmente quindi i driver di più alto livello, come i 
file system, girano continuamente in modo interrompibile (usando la 
terminologia Windows, il loro IRQL è PASSIVE_LEVEL), più ci avviciniamo 
all'hardware, più ci avviciniamo a codice real time, e più interrupt 
vengono disattivati. Tutto chiaro?


 piccolo e veloce, da non farsi neanche sentire.
lo è, lo è. Solo che quando dipende dall'hardware non si può mai sapere



Probabilmente piu' che storie di orrore saranno storie derivate da
uso di allucinogeni..
-- 
Pierluigi De Rosa (
tho...@durin.khazad-dum.net
).
<<      LINUX: the choice of a GNU generation     >>
<<   For my real address... ask the Balrog.       >>
* Sostenete la Lega per la Soppressione dei Troll *

 Il modo cooperativo puo' risolvere dei problemi ma ne puo' inserire altri.
Il problema e` che la preeption inserisce
"imprevedibilita`", il che non ha senso a
livello kernel, dove tutto deve essere
sotto stretto controllo.
L'approccio cooperative, invece, mantiene
questo controllo, pur consentendo multitasking.
Secondo me in maniera sufficiente per cio`
che e` richiesto ad un kernel.
bye,
-- 
  Piergiorgio Sartor

 lo è, lo è. Solo che quando dipende dall'hardware non si può mai sapere
Non deve dipendere dall'HW, mi pare semplice.
bye,
-- 
  Piergiorgio Sartor

 vengono disattivati. Tutto chiaro?
Lo era anche prima :-)
Pero` non mi sentirei di definire il FS un driver,
non so perche`, ma restituire la trota, pardon, il
salmone :-)
bye,
-- 
  Piergiorgio Sartor

 che e` richiesto ad un kernel.
In linea di principio posso anche essere d'accordo pero' mi sembra di
ricordare che entrambi gli approcci vengano utilizzati e questo
significherebbe che ci sono situazioni in cui e' utile usare la preemption.
La cosa migliore da fare sarebbe quella di fare una ricerca per vedere in
quali quantita' vengono usati i due approcci e quali sono i casi in cui
viene usata la preemption.
Ciao, Davide.

 processi user.
Mi sembra strano. Cosa avviene quando faccio una system call da un 
processo utente? Ora qua' non so bene cosa succeda in particolar in 
linux, ma non so se viene instanziato un thread del kernel che soddisfi 
la particolare richiesta. Penso piuttosto che il processo dell'utente 
entri in kernel mode (con tutte le protezioni del caso) ed esegua il 
codice associato alla system call, cosa che potrebbe comportare la 
modifica di struttre dati di sistema. E qui' c'entra il problema della 
rientranza.
Ditemi pure se dico cavolate.

 viene usata la preemption.
Certamente, ma non mi va... :-)
bye,
-- 
  Piergiorgio Sartor

 rientranza.
Esatto, ma il problema e` piu` complicato.
Il kernel e` piuttosto monolitico ed abbastanza
non interrompibile, se succede, per qualche motivo,
che si debba aspettare qualcosa in kernel mode,
magari sarebbe il caso di pensare a fare qualcos'altro,
nel frattempo.
Da qui la necessita` di avere un kernel preemptable.
La cosa, pero`, non mi e` chiara, a me sembra di capire
vi sia qualche limitazione del design iniziale.
bye,
-- 
  Piergiorgio Sartor

 uso di allucinogeni..
Dici che la piccola Maya abusi? :-)
bye,
-- 
  Piergiorgio Sartor

vai che sono curiosissimo


 vi sia qualche limitazione del design iniziale.
Non tutto il  codice del kernel e` stato scritto  per essere rientrante.
Inoltre, una  preemption mentre  il codice (del  kernel) ha  bloccato un
lock (qualunque, purche`  non un BKL, quelli sono un  caso a parte) puo`
condurre ad un deadlock.
Per  la  reentrancy e  la  preemtion  a livello  di  kernel  ci sono  da
tempo  patch  (nei 2.5)  di  Robert  Love. Per  le sezioni  critiche  ci
sono  le funzioni  preempt_enable()/preempt_disable() che  permettono di
abilitare/disabilitare la preemption.
ciao
Kronos
-- 
Home: 
http://kronoz.cjb.net
Runtime error 6D at f000:a12f : user incompetente

 come thread.
Il termine, in  effetti, un po' fuoriante. I kernel thread  non sono dei
veri e  propri thread. In  primo luogo  non hanno  un proprio  spazio di
indirizzamento (quindi current->mm == NULL). In secondo luogo girando in
kernel  mode  (ovvio),  e,  a  meno di  non  utilizzare  un  kernel  con
preemption,  non sono  interrompili (devono  chiamare schedule()  quando
hanno fatto quello  che devono fare). In terzo luogo  vengono gestiti in
maniera un  po' particolare  dallo scheduler, visto  che al  momento del
calcolo della goodness hanno un boost.
ciao
Kronos
-- 
Home: 
http://kronoz.cjb.net
Non sempre quello che viene dopo e` progresso.
Alessandro Manzoni

 Il termine, in  effetti, un po' fuoriante. I kernel thread  non sono dei
[...]
Yep.
Grazie della spiegazione, in effetti ora le
cose mi sono piu` chiare.
bye,
-- 
  Piergiorgio Sartor

 della richiesta...
Ehm, hai ragione. Mi pare che cosi' il thread del driver abbia le 
funzioni di un monitor. Non ricordo molto bene, visto che ho studiato 
queste cose tanti anni fa, ma mi pare che il monitor non e' sempre la 
soluzione piu' conveniente. Anzi, non ricordo neanche perche' potessero 
essere usati al posto di una gestione accurata delle sezioni critiche.
Indovinate su che libro ho studiato!

 condurre ad un deadlock.
No, intendevo, non capisco perche` serva la
preemption, secondo me non dovrebbe essere
necessaria, se non per qualche "difetto" di
design... Diciamo...
bye,
-- 
  Piergiorgio Sartor


Ci provo: forse perche' cosi' non e' necessario di fare il polling
dei thread per trovarne uno "pronto", almeno per quelli ad alta priorita'
(penso all'pproccio interrupt vs. polling per la gestione degli eventi).
Alessandro.

 (penso all'pproccio interrupt vs. polling per la gestione degli eventi).
Uhm, non credo, comunque se fosse cosi`...
Eliminerei i thread seduta stante.
Penso che entrare ed uscire dai thread possa
comunque essere cooperative, non necessariamente
preemptive.
bye,
-- 
  Piergiorgio Sartor

cose mi sono piu` chiare.
se non ci fosse Kronos in questo mondo a mettere un pò di chiarezza :)
--
Rhymes
rhy...@myself.com
" ride or die "

 se non ci fosse Kronos in questo mondo a mettere un pò di chiarezza :)
Eccerto, dopo Caos, viene Kronos...
bye,
-- 
  Piergiorgio Sartor

 design... Diciamo...
Supponi  che ad  un dato  istante  ci sia  un solo  processo pronto  per
l'esecuzione, lo scheduler lo seleziona e lo manda in esecuzione. Questo
processo esegue una syscall. Mentre e` in corso di esecuzione la syscall
arriva un interrupt, l'interrupt "sveglia"  un processo a priorita` piu`
elevata (o magari realtime).
A questo punto ci sono due scenari: nel kernel "normale" viene terminata
la gestione della  syscall (che puo` richiedere ancora alcuni  ms) e poi
il processo corrente  viene sostituito con quello ad  alta priorita` (mi
pare che ci sia un controllo dei SoftIRQ sul return path, vero?).
In un kernel preemptible il  processo a bassa priorita` viene interrotto
anche se si trova all'interno della  syscall ed il nuovo processo inizia
subito l'esecuzione.
Il  risultato e`  una minore  latenza  (si nota  molto con  applicazioni
interattive e sistema carico) e, in alcuni casi, un aumento del tput. In
caso di applicazioni realtime la patch riduce drasticamente il numero di
deadline mancate.
Non  so come  funzioni la  cosa in  un  OS a  ukernel, ma  in teoria  il
problema dovrebbe farsi  sentire di meno, visto che  parte delle syscall
viene girata a processi in userspace.
L'argomento e` stato trattato piu`  in profondita` dallo stesso Love sul
numero di Maggio del Linux Journal.
ciao
Kronos
-- 
Home: 
http://kronoz.cjb.net
Sono un mirabile incrocio tra Tarzan e Giacomo Leopardi.
In me convivono tutte le doti intelluttuali di Tarzan e
tutta la prestanza fisica di Giacomo Leopardi.
A. Borsani

 subito l'esecuzione.
Certo, cosi` ha senso, ma la situazione, secondo
me, non dovrebbe proprio accadere.
BTW, in giro ci sono 2 patch: low latency scheduler
(introdotto gia` nella serie 2.4, almeno da RH) ed
il patch preemptive (che immagino sia quello che tu
descrivi qui).
Leggevo che la combinazione dei due da ottimi risultati,
specie con macchina a pieno carico (in termini di numero
di processi in esecuzione).
bye,
-- 
piergiorgio

 ed il patch preemptive (che immagino sia quello che tu descrivi qui).
Esatto.
ciao
Kronos
-- 
Home: 
http://kronoz.cjb.net


 Marcelo non lo accettera` per il merge nella mainline.
Perche` dici di no?
bye,
-- 
piergiorgio

Eccerto, dopo Caos, viene Kronos...
guarda che io Kronos lo conosco..parlavo seriamente


 Perche` dici di no?
Perche` la mainline ha  iniziato a stabilizzarsi. Vengono accettati solo
bugfix  e  poche  altre  cosette. Un  nuovo  scheduler  (come  ha  anche
affermato piu` volte  Ingo sulla lkml) richiede prima una  lunga fase di
testing, non e` certo il genere di patch che viene inserita su un kernel
stabile.
ciao
Kronos
-- 
Home: 
http://kronoz.cjb.net


 guarda che io Kronos lo conosco..parlavo seriamente
La mia era una citazione... Seria...
bye,
-- 
piergiorgio

 stabile.
Ma come mai RH o Cox lo hanno inserito nella
loro distribuzione?
bye,
-- 
piergiorgio

stabile.
Come cavolo fai a stare dietro alla lkml? Io ho resistito meno di un
mese :(


 Dici che la piccola Maya abusi? :-)
sono illazioni! non ho mai spento la ventolina della CPU per annusare i 
fumi di plastica e silicio! è una menzogna!


 pari a quella della perduta Biblioteca d'Alessandria. <g>
mi spiace, ma mi manca l'anatomia per fare a chi ce l'ha piů lungo. Se 
vuoi possiamo fare a chi piscia piů lontano


 Non deve dipendere dall'HW, mi pare semplice.
uh-hu *pat pat* <carezza Piergiorgio sulla testa>


 Pero` non mi sentirei di definire il FS un driver,
lo è, che ti piaccia o meno. Deve poter creare e manipolare oggetti 
kernel direttamente, e dialogare direttamente con la periferica 
sottostante, quindi lo è


 uh-hu *pat pat* <carezza Piergiorgio sulla testa>
No, sul serio, il sistema deve essere
prevedibile, come credi facciano i SO
real-time?
bye,
-- 
piergiorgio

 mi spiace, ma mi manca l'anatomia per fare a chi ce l'ha più lungo.
Ah, ma allora puoi dibattere con thorin! =)

 sottostante, quindi lo è
No, non dialoga con la periferica, ma con
il _driver_ della periferica, il che rende
questionabile la definizione di "driver",
forse "handler" sarebbe piu` corretto.
Tant'e` che anche il TCP/IP si trova nella
stessa condizione e non e` chiamato "driver",
ma "stack".
bye,
-- 
piergiorgio

 fumi di plastica e silicio! è una menzogna!
Toh, questa e` nuova, ero rimasto
alla pasta siliconica...
bye,
-- 
piergiorgio

fumi di plastica e silicio! è una menzogna!
E dovresti sentire con un po' di trielina... :)
**Togli gli asterischi dall'indirizzo per rispondere in e-mail

 loro distribuzione?
Perche' e' "cool" :)
-- 
Lorenzo

 mese :(
Seguo questo: fa.linux.kernel (il newsserver  crucco lo porta), e` un ng
su cui vengono convogliate le email.
Con  il getpost  ci metto  un attimo  a scaricare. Ovviamente  non leggo
tutti i thread, solo quelli che mi interessano.
ciao
Kronos
-- 
Home: 
http://kronoz.cjb.net
Windows NT crashed.
I'm the Blue Screen of Death.
No one hears your screams.

su cui vengono convogliate le email.
grazie l'ho appena sottoscritto...


 fumi di plastica e silicio! è una menzogna!
Merendina - Ciambellina Misterday di annata buona con sopra polverina
bianca di origine Columbiana?
Saluti.

 uh-hu *pat pat* <carezza Piergiorgio sulla testa>
Beh, almeno questa e` meglio della trota...
bye,
-- 
  Piergiorgio Sartor

 famoso, che o bloccano troppa roba, o frazionano troppo
Su questa non avevo pensato, ma da quando in
qua serve un kernel thread per serializzare
le operazioni sul floppy?
Il "trackdisk.device" si occupa di tutto e
tutto e` interrupt driven, connesso allo
scheduler, ovviamente.
Mai sentito che servano thread o spinlock...
Tra l'altro questa storia degli spinlock non
la capisco.
Da quello che ho letto sarebbero busy waiting
loop dentro il kernel (di Linux), usati perche` 
l'irq sarebbe troppo lento...
Mi sfugge il senso, anche qui...
bye,
-- 
  Piergiorgio Sartor

 bianca di origine Columbiana?
E si che tu te ne intendi, eh? :-)
-- 
Pierluigi De Rosa (
tho...@durin.khazad-dum.net
).
<<      LINUX: the choice of a GNU generation     >>
<<   For my real address... ask the Balrog.       >>
* Sostenete la Lega per la Soppressione dei Troll *

 Mi sfugge il senso, anche qui...
Sono una cosa tipo:
     #define spinlock_lock(spinlock) \
         while (!mutex_try_lock(spinlock->mutex)) {};
     #define spinlock_unlock(spinlock) \
         mutext_unlock(spinlock->mutex)
Ovviamente non sono le definizioni esatte, è solo per rendere l'idea.
Si usano nel kernel, quando si servono gli interrupt e quindi non si 
possono usare altri tipi di lock perché non si può mettere il 
processo/thread in attesa.
-- 
"Everything is vague to a degree you do not realize till you have tried
  to make it precise"
                                       Bertrand Russell
                                       The Philosophy of Logical Atomism

 processo/thread in attesa.
La domanda e`: perche` si dovrebbe usare un lock
dentro il kernel?
Questo non capisco.
In kernel mode si e` gia` locked, per definizione.
Oppure c'e` altro?
bye,
-- 
  Piergiorgio Sartor

 Mi sfugge il senso, anche qui...
Semplicemente, servono per la mutua esclusione nei SMP
e ora anche nei UP con kernel preemption.
-- 
Lorenzo

 Oppure c'e` altro?
C'è che il kernel NON è locked. Se arriva l'interrupt associato al task 
switching mentre un processo è in kernel mode, si passa ad un altro 
processo, mentre l'altro rimane in kernel mode, dormendo.


 processo, mentre l'altro rimane in kernel mode, dormendo.
Da quello che ho capito questo succede solo
con un recente patch e non e` la prassi.
Secondariamente, anche se fosse, non spiegherebbe
gli spinlock.
bye,
-- 
  Piergiorgio Sartor

 e ora anche nei UP con kernel preemption.
OK, era una questione SMP, originariamente,
questo rende tutto molto piu` chiaro.
Riguardo al kernel preemtable, invece, ancora
non capisco cosa c'entri.
Puoi fare qualche esempio?
bye,
-- 
  Piergiorgio Sartor

 gli spinlock.
Su questo passo la parola a qualcun altro perché sinceramente anche a me 
gli spinlocks non piacciono tanto.


 gli spinlocks non piacciono tanto.
Neanche a me, per questo chiedo...
bye,
-- 
  Piergiorgio Sartor

 A meno che non si intenda altro.
Si intende che per fare I/O asincrono l'applicazione non deve generare 
dei task suoi, ma semplicemente usa il supporto dato dall'OS, che è _di 
default_ rivolto ad un uso massicciamente parallelo.


 L'api è composta essenzialmente da tre funzioni:
Sorry, erano 4 :)


 default_ rivolto ad un uso massicciamente parallelo.
Si, ma non necessita thread, il kernel intendo.
Basta usare opportunamente, le risorse a disposizione,
in maniera molto piu` semplice e pulita.
Tipo i segnali, dal driver, per comunicare al task
che l'I/O e` pronto (e questo si fa gia`, senza thread)
A meno di non avere un uK, in questo caso le
cose cambiano, la soluzione Amiga (task o thread
intendo) diventa la migliore.
bye,
-- 
  Piergiorgio Sartor

 Sorry, erano 4 :)
Me ne ero accorto... ;-)
bye,
-- 
  Piergiorgio Sartor

 A me piacciono le storie d'orrore, raccontami un po'...
facciamo che ve lo racconto stasera. Promesso. Ora sto ripassando la 
buffer cache


 facciano i SO real-time?
ma lo scopo dei sistemi real-time *è* di essere prevedibili. Lo scopo 
degli altri è un po' diverso


 chiamato "driver", ma "stack".
uh-hu *pat pat*. Windows divide i driver in bus driver, class driver, 
device driver e filesystem driver [1] - approssimativamente [2] - e 
*nessuno* di questi parla direttamente con l'hardware, tranne i bus 
driver per ovvie ("qualcuno dovrà pur farlo") ragioni. E con questo 
chiudo il discorso, chè non ne capisco più il senso
[1] Se ti interessa capire la distinzione, nel caso di un hard disk il 
file system sarà NTFS, FAT, o quello che vuoi, la device sarà l'hard 
disk, la classe sarà "storage", e il bus sarà il driver IDE. Nel caso 
della scheda ISDN il file system non c'è (ovviamente), la device sarà 
la scheda, la classe sarà "network", il bus sarà PCI. E così via
[2]
 - con il PnP le cose cambiano leggermente. L'unica distinzione netta 
rimane quella tra bus driver e "tutti gli altri", e vengono introdotti 
i filter driver. I filesystem sono di livello abbastanza alto da poter 
rimanere sostanzialmente invariati nella nuova architettura
 - TCP è il sottoinsieme di un'architettura a parte, TDI. Per quello ti 
rimando a 
http://www.pcausa.com/resources/winpktfilter.htm
, c'è una 
bella mappa delle architetture TDI (più che altro del TCP/IP) e NDIS.


 Toh, questa e` nuova, ero rimasto alla pasta siliconica...
e dirň di piů, prova a farlo mentre gira seti@home



La preempt patch sfrutta l'impianto di mutua esclusione gia' offerto per 
i SMP, cioe' gli spinlock.
Il kernel ora e' sempre "preemptible" tranne in due casi:
1) il processo che stava facendo la syscall si trova in quel momento
in una sezione critica protetta da spinlock.
2) Altri (pochi) casi speciali.
Questo ha permesso di "fondere" una parch di pochi kb e relativamente
semplice.  In pratica con questa patch hai un kernel compilato SMP, 
anche se lo usi per un monoprocessore.
BTW, questo ha anche il vantaggio che i bug dei kernel SMP sono scoperti
prima e in numero maggiore dato che i monoprocessori rappresentano il 
99,9% della base installata ;)
-- 
Lorenzo

Maya ha scritto:
DISCLAIMER: sto imparando queste cose mentre le dico, quindi potrebbero 
essere tutte boiate. Non dare troppo peso a niente di quello che dico
-- 
 < 
http://www.reactos.com/
 >  Open source clone of Windows NT. Current
     Don't stand, REACT!      version 0.0.19. C, C++ and ASM developers
                              and beta testers are welcome!

 A me piacciono le storie d'orrore, raccontami un po'...
m'è passata la voglia, ma visto che insistete...
allora. Per l'esame di Sistemi Operativi c'era da preparare un piccolo 
progetto, giusto per dimostrare di aver assimilato le system call di 
Unix. Conseguentemente, il programma da sviluppare non deve fare nulla 
di utile (tenere dieci interi in memoria condivisa e fare finta che 
siano dei job da processare, se ci tenete tanto a saperlo). Per cui io 
e il mio compare, con (per) cui ho sviluppato il progetto, l'abbiamo 
soprannominato Bogotron 2000. Il Bogotron, da piccolo stupido programma 
che era inizialmente (e che la specifica richiedeva), ha visto una 
crescita incontrollabile nell'arco degli ultimi due-tre mesi (no, non 
invia ancora le e-mail), fino a diventare un mostro da 1800 linee di 
codice (prego ricordare: il programma non fa *niente*). Nonostante 
questo, è rimasto stabilissimo. Beh, a parte un misterioso SIGSYS che 
abbiamo attribuito ad un bug di Solaris. E ad una serie di pittoreschi 
errori (tra cui un SIGBUS) quando per sbaglio re-linkavamo l'eseguibile 
mentre era in uso (ma non dovrebbe dare un errore ETXTBUSY? mah), che 
lasciavano ld confuso e felice. Per essere assolutamente sicuri che 
fosse stabile e non andasse in crash proprio durante la demo, abbiamo 
aggiunto all'ultimo momento al client un comando "stress", che sparasse 
richieste a casaccio, valide e non valide, al server, forkandosi in 
continuazione. Problemino: mi sono dimenticata di mettere una wait per 
ripulire i processi creati in questo modo. Il comando "stress" è girato 
per qualche minuto, e poi la macchina (Solaris 5.6 su Sun Blade 100) 
s'è inchiodata. Funzionava solo più il kernel (telnettando da un'altra 
macchina la connessione riusciva, ma il demone non rispondeva). Ah, sì, 
e il cursore del mouse si muoveva ancora. Abbiamo chiamato un tecnico, 
che ha provato invano una serie di manovre di rianimazione, e alla fine 
ha dovuto rassegnarsi al reset, bofonchiando qualcosa tipo "sembrava un 
problema di risorse esaurite...". Probabilmente è una maledizione che 
grava su questo esame. Il mio compare mi ha raccontato di un suo amico 
che aveva realizzato un programma simile, con un problema simile, che 
al posto dei processi però usava i thread: la macchina si bloccò, e al 
riavvio c'erano 3 GB di swap file. Ah, avevo promesso qualcosa anche 
per Linux, vedo. Spiacente, malinteso


 polverina bianca di origine Columbiana?
le MisterDay non mi sono mai piaciute


 per Linux, vedo. Spiacente, malinteso
C'e' una interessante trasmissione, la notte, su TeleBogus, chiamata "il
mio amico ulimit e gli gnomi della foresta" :o)
(ce n'e' anche un'altra dal titolo "Sysinstall e la mattanza dei
LinuxServer" ma tratta altri argomenti).

 degli altri è un po' diverso
Allora rispiegami un po', anche a
parole tue, in quale caso i tempi
di attesa nel kernel (si parlava di
questo?) dipendono dall'HW.
Secondo me, non dovrebbe accadere
e sinceramente, pensando al mio
PC, non mi viene in mente niente.
Ma puo` essere che ci sia qualcosa
che mi sfugge.
bye,
-- 
piergiorgio

 uh-hu *pat pat*. Windows divide i driver in bus driver, class driver, 
Windows puo` dividere o moltiplicare i
driver come gli pare, questo non vuol
dire che la cosa sia esatta o corretta
ne` tantomeno sensata.
[cut sfoggio di conoscenza di NT]
A questo punto, per evitare confusioni,
bisogna accordarsi sul concetto di
"driver". Gia` tempo addietro vi fu questa
discussione (come sempre infruttuosa).
Per cui non vorrei riprenderla, mi basta
sottolineare che ci possono essere diverse
interpretazioni del concetto.
bye,
-- 
piergiorgio

 Il kernel ora e' sempre "preemptible" tranne in due casi:
[...]
OK, questo e` anche molto istruttivo.
bye,
-- 
piergiorgio

 e dirň di piů, prova a farlo mentre gira seti@home
Ho il sospetto che duri troppo poco,
non e` che ci sia qualche "soluzione"
intermedia?
Chesso`, magari partendo dal CD burner,
passando per l'HD, per finire sulla CPU?
bye,
-- 
piergiorgio

codice (prego ricordare: il programma non fa *niente*). 
1800 linee di codice per nulla?!
--
Rhymes
rhy...@myself.com
" ride or die "

 mio amico ulimit e gli gnomi della foresta" :o)
Ma, nooooo.... :-)
bye,
-- 
piergiorgio

 Ma, nooooo.... :-)
Ma si', e' subito dopo il "login.conf late show".

 Ma si', e' subito dopo il "login.conf late show".
Dimmi un po', fra noi due, non e` che
c'e` anche qualche, come dire, spettacolo
un po' piccante?
bye,
-- 
piergiorgio

 Ma nel caso singola CPU?
C'e' un buon articolo di Robert Love (l'autore) su LJ:
http://www.linuxjournal.com/article.php?sid=5833
-- 
Lorenzo

 
http://www.linuxjournal.com/article.php?sid=5833
Si, ma parla esaustivamente del caso SMP,
solo accennando il caso UP.
bye,
-- 
piergiorgio

 i semafori.
http://www.linuxdevices.com/articles/AT8906594941.html
[...]
The preemption patches added a variable to the task structure (the 
structure that maintains state for each thread) named preempt_count . 
The preempt_count field is modified by the macros preempt_disable(), 
preempt_enable() and preempt_enable_no_resched() . The 
preempt_disable() macro increments the preempt_count variable, while 
the preempt_enable*() macros decrement it. The preempt_enable() macro 
checks for a reschedule request by testing the value of need_resched 
and if it is true and the preempt_count variable is zero, calls the 
function preempt_schedule() . This function marks the fact that a 
preemption schedule has occurred by adding a large value (0x4000000) to 
the preempt_count variable, calls the kernel schedule() function, then 
subtracts the value from preempt_count. The scheduler has been modified 
to check preempt_count for this active flag and so short-circuit some 
logic in the scheduler that is redundant when being called from the 
preemption routine. 
The macro spin_lock() was modified to first call preempt_disable(), then 
actually manipulate the spinlock variable. The macro spin_unlock() was 
modified to manipulate the lock variable and then call 
preempt_enable(), and the macro spin_trylock() was modified to first 
call preempt_disable() and then call preempt_enable() if the lock was 
not acquired. 
In addition to checking for preemption opportunities when releasing a 
spinlock, the preemption patches also modify the interrupt return path 
code. This is assembly language code in the architecture specific 
directory of the kernel source (e.g. arch/arm or arch/mips) that makes 
the same test done by preempt_enable() and calls the preempt_schedule() 
routine if conditions are right.
[...]
In breve, la patch sfrutta l'impianto gia' esistente delle sezioni
critiche protette da spinlock ma ne modifica l'implementazione.
-- 
Lorenzo

 Secondariamente, anche se fosse, non spiegherebbe gli spinlock.
Come faresti per i lock? Gli spinlock  vengono utilizzati per il lock di
parti molto  piccole e veloci di  codice (lo spin [3]  dura pochissimo),
per il resto (dove ci si puo` permettere un blocco) si usano i semafori.
[1] Pensa ad un floppy: l'accesso e` decisamente piu` lento della
possibile latenza introdotta da una sleep_on().
[2] Pensa ad un HD: qui` una sleep_on() potrebbe alzare in maniera
notevole la latenza.
[3] Come gia` detto lo spin c'e` solo in sistemi MP, con una sola CPU
non avrebbe senso.
ciao
Kronos
-- 
Home: 
http://kronoz.cjb.net
Porc i' mond che cio' sott i piedi!
V. Catozzo

 non avrebbe senso.
Era proprio questo che volevo sapere.
bye,
-- 
piergiorgio

 notevole la latenza.
Qui torniamo al problema del codice del
kernel, che deve essere il piu` veloce
possibile.
Le periferiche piu` veloci, solitamente
hanno un qualche DMA, che consente di
trasferire piu` dati, quindi di prendere
piu` tempo e conseguentemente di consentire
un suspend completo sull'irq.
bye,
-- 
piergiorgio

 restore_flags(flags);
Forse ci manca la riabiliatazione degli irq?
Comunque il problema non era questo, e` chiaro
ed evidente che servono le sezioni critiche, il
problema era sulla confusione dei termini.
"spinlock" mi sta a significare che c'e` un
busy waiting loop, il che non e` concepibile,
in sistemi SP.
Certo, per i casi MP il discorso potrebbe
cambiare.
bye,
-- 
piergiorgio

 un suspend completo sull'irq.
Questo cosa c'entra? Il master imposta il trasferimento, e poi fa altro.
Non rimane bloccato. La periferica manda un interrupt quando ha finit o.
ciao
Kronos
-- 
Home: 
http://kronoz.cjb.net
I went to God just to see
And I was looking at me
Saw heaven and hell were lies
When I'm God everyone dies

 Forse ci manca la riabiliatazione degli irq?
No,   save_flags()   e`   stata   chiamata  prima   di   cli(),   quindi
restore_flags() rimette tutto a posto.
 
ciao
un Kronos che vado al mare :)
-- 
Home: 
http://kronoz.cjb.net
"Chi parla in tono cortese, ma continua a prepararsi, potra` andare avanti;
 chi parla in tono bellicoso e avanza rapidamente dovra` ritirarsi" 
Sun Tzu -- L'arte della guerra

 Non rimane bloccato. La periferica manda un interrupt quando ha finit o.
Esatto, quindi dov'e` il problema?
Qui stiamo parlando di _spin_lock su sistemi
SP, ed ancora non mi e` chiaro quando uno
dovrebbe usarli.
O meglio, non mi e` chiaro cosa vogliono dire,
sono esattamente lo stesso concetto di sezione
critica, o no? Dove sta la novita`?
bye,
-- 
piergiorgio

 restore_flags() rimette tutto a posto.
Ah, OK, perche` i flag contengono anche
il bit per gli irq, chiaro.
bye,
-- 
piergiorgio

 1800 linee di codice per nulla?!
yep. Quasi tutti i parametri sono opzioni che si possono passare sulla 
riga di comando, e questo ha aggiunto un bel po' di codice. Per non 
parlare del parser dei comandi del client. Considera poi che C non ha 
le eccezioni, quindi devi passare tutto il tempo a controllare valori 
di ritorno


 Era proprio questo che volevo sapere.
sui sistemi monoprocessore acquisire uno spinlock significa solo 
aumentare l'IRQL (in Windows almeno fino a DISPATCH_LEVEL, abbastanza 
per disattivare la pre-emption). Rimane un'azione pericolosa (il DDK 
consiglia di non tenere uno spinlock per più di 25 microsecondi)


 consiglia di non tenere uno spinlock per più di 25 microsecondi)
Pericolosa? Direi inevitabile, c'e` un
altra possibilita`?
bye,
-- 
piergiorgio

 Pericolosa? Direi inevitabile, c'e` un altra possibilita`?
fare in modo da non usarli o usarli il meno possibile :-) cos'è, ora 
sono io a dirti "il design non lo dovrebbe richiedere"? ;-)


di ritorno
già...è una delle più grandi pecche del C :(


 sono io a dirti "il design non lo dovrebbe richiedere"? ;-)
No, perche`?
Tutto il problema nasce dal fatto che
esistono gli irq e che sono asincroni.
Quindi esiste la possibilita` di due
richieste contemporanee, bisogna
sbrogliarala, non essendo possibile
disponibile (ma e` possibile) in HW,
bisogna farlo in SW...
Oppure hai alternative?
bye,
-- 
piergiorgio

che tutti, o molti limiti vengono rimossi. 
è quello che in win viene definito ring 0?


 č quello che in win viene definito ring 0?
Da quello che mi pare di aver capito,
questo fantomatico "ring 0" e` una
invenzione intel, piu` che Microsoft.
bye,
-- 
piergiorgio

 
Lo scheduling del processore è un argomento presente in ogni libro di SO, 
non è difficile da trovare. 
-- 
Renato "Hitman" Salzano | 
http://spazioinwind.iol.it/hitman/
GdG #6 - Mexico 86 Fan #2 - VFNCL counter - Transbassista dei 2ofSpades
"You think the way you live is okay / Your simple posin’ will save the day
 You think we don’t see / That you’re running" - Rockstar, N*E*R*D

 
Non mi risulta che il FS dialoghi direttamente con le periferiche, ma 
passi i dati a livello di block ai drivers di dovere (HD, FD, ecc). 



Il fatto che un SO chiami "driver" cose che in informatica classica non lo 
sono non è che modifichi la definizione classica.
Da quel che si legge in ogni testo di SO, il driver è solo la parte di SW 
che dialoga direttamente con l'HW, tutto il resto non lo è. 


 
Vero. In effetti si tratta di concetti astratti, l'implementazione è 
secondaria. 
