Newsgroup: it.comp.os.dibattiti
Titolo: multitasking

che differenze ci sono a basso livello fra:
- multitasking di tipo preemptive 
- multitasking di tipo cooperative
- multithread
Linux che tipo di multitasking ha?
e winXP ?
- win9x ?
- beos?
- unix?
- os/2
spero che non sia OT
Ciao

Linux che tipo di multitasking ha?
Preemptive se non erro (cosi' come Win).
--
Naquern Yansbetevn
naquern.y...@africamail.com

 - os/2
preeemptive e multithreading dalla versione 2... quando gli utenti
dos usavano si e no win3.0...
--
ciao, Mirco.
[ Icq#:51640305 ] [ 
http://spazioweb.inwind.it/mmos2/
 ]

veramente non lo so.
Confermo, preemptive.
Viene implementata la tipica tecnica "round-robin".
--
Naquern Yansbetevn
naquern.y...@africamail.com

 veramente non lo so.
Preemptive su applicazioni win32, cooperative su quelle win16.
Saluti.
--
Wilmer Ricciotti
wi...@bigfoot.com

Viene implementata la tipica tecnica "round-robin".
nope, č un cooperativo trasparente. La funzione (non documentata) 
EnterSysLevel permette a qualsiasi processo, quale che sia il suo ring, 
di bloccare tutti gli altri e rimanere l'unico in esecuzione. Si basa 
tutto sul cosiddetto "Win16Mutex", un oggetto di sincronizzazione 
residente nel primo MB di memoria fisica, nonostante il nome non un 
mutex ma una sezione critica. Il sistema operativo ne entra 
temporaneamente in possesso durante operazioni che non devono essere 
assolutamente interrotte, niente vieta perň a un processo a 16 bit mal 
progettato o a un processo a 32 bit scritto ad hoc di prenderne possesso 
e non rilasciarlo mai piů

 - os/2
passo

spero che non sia OT
E' uno dei messaggi piu' in IT che abbia mai visto su questo NG..
-- 
Lorenzo
(address rot13 encoded)

nope, è un cooperativo trasparente. 
"Per ogni thread eseguito, il sistema stabilisce un tempo di
CPU.  Esso crea l'illusione che tutti i thread siano
eseguiti contemporaneamente offrendogli porzioni di tempo
(chiamate quantum) in una modalita' round-robin".
["Programmare Applicazioni per Microsoft Windows", Jeffrey
Ritcher].
--
Naquern Yansbetevn
naquern.y...@africamail.com

preemptive, non multithreading
Linux ha un multithreading che e' piu' generale di quello Win*, man
clone(2). Anche i *BSD con rfork(2) hanno un modello simile.


clone(2). 
che è una funzione non standard... e mi stupisco che una funzione simile 
sia usabile dal di fuori del kernel... un po' TROPPO generale, non 
trovi? sarà che il concetto vero e proprio di "thread" non esiste, e se 
la devono cavare con questi accrocchi...
in ogni caso, finchè ps non mi mostrerà il numero di thread di ogni 
processo in esecuzione (senza barare, mettendo "1" quando in realtà 
semplicemente non lo sa), continuerò a ripetere che Linux non è 
multithreading (per contro: di fork() ci sono implementazioni anche su 
Windows, questo non significa che vanno usate)
PS: non vorrei sembrare polemico, ma multithreading e Unix non mi sembrano
volersi molto bene. Forse mi sbaglio, ma fork mi sembra la soluzione
migliore nella maggior parte dei casi

Preemptive su applicazioni win32, cooperative su quelle win16.
ma una delle 100 leggendarie funzioni non documentate di kernel32.dll, 
_EnterSysLevel, permette a qualsiasi applicazione Win32 di sovvertire 
completamente il multitasking...

Ritcher].
Lascia stare quella robetta e leggiti un libro serio, tipo "Windows 
System Programming Secrets" di Matt Pietrek

 migliore nella maggior parte dei casi
Non so come siano messi a standard (POSIX & co.), ma il
threading va preso con le molle.
Cioe`, ad es., se un task apre dei file e poi crea dei
thread ed uno di questi chiude un file, cosa succede?
Il genitore si trova con il file chiuso o solo il thread?
E gli altri thread?
Chiaramente si puo` definire un diverso numero di "livelli"
di sicurezza e, conteporaneamente, di prestazioni.
Quello che ho visto accadere e` che ognuno si sogna diverse
formulazioni del "threading", con diverse opzioni in casi
critici, come l'esempio di cui sopra.
Questo cosa c'entra con Unix? C'entra il fatto che in
diversi Unix il threading e` implementato diversamente,
a seconda di cosa il designer vuole fare...
Immagino, comunque, che vi siano delle definizioni (POSIX)
su come il threading vada implementato.
Immagino anche, che gli standard siano una gran cosa ed
ognuno dovrebbe averne uno suo... :-)
bye,
-- 
  Piergiorgio Sartor

 - win9x ?
cooperative anche se teoricamente dovrebbe essere possibile intervenire
sui singoli processi <ctrl+alt+canc> ed e' il motivo della sua
instabilita', difatti bloccando un singolo processo spesso si ottiene il
parziale <inteso come operazioni di background> o anche totale blocco
del so
--
Non sara' cosi' lamer....non sara' cosi' lamer.........

 E' uno dei messaggi piu' in IT che abbia mai visto su questo NG..
Sono perfettamente d'accordo con te! Ma che windows sia
preempitive.......diciamo che vorrebbe esserlo, ma non dimenticare che fino
a win 98 c'era il dos a gestire tutto, forse ti riferivi a NT.


 - os/2
Ignoro. Immagino preemptive come tutti i SO moderni.
-- 
Renato "Hitman" Salzano - 
http://spazioweb.inwind.it/hitman/
 
e-posta : sonicblast (at) 
inwind.it
 / Fan di Helena Velena 
"Qualche volta sogni, anima, fantasia e realta` si mescolano, e i loro
 confini sfumano fino a sparire. E mi e` piaciuto" (Io, riflettendo)

Lascia stare quella robetta
Per favore...
--
Naquern Yansbetevn
naquern.y...@africamail.com

migliore nella maggior parte dei casi
Certamente.


 Ignoro. Immagino preemptive come tutti i SO moderni.
preemptive... e multhreading da quasi 10 anni...


di bloccare tutti gli altri e rimanere l'unico in esecuzione.
*brivido*
Leonardo
-- 
Microsoft Outlook: il primo news reader con supporto messaggistica RAID 1.

questi chiude un file, cosa succede?
Boh, probabilmente c'e' un contatore associato al FD.
A me il multithreading non piace  per il semplice fatto che complica
la vita al programmatore :-)
-- 
 __
| _         "The Internet is slow, could you please reboot it ?"
|__|iambo   mailto:
gabr...@giambonini.com
 
www.giambonini.com

Non e' il solo possible, fortunatamente.
E' solo un fatto di terminologia. S'è dato il nome "processo" allo 
spazio di indirizzamento, e "thread" al codice effettivamente in 
esecuzione, tutto qui

 la vita al programmatore :-)
Devi pur guadagnarti la via per il paradiso dei programmatori
od almeno quella per raggiungere l'illuminazione :-)
bye,
-- 
  Piergiorgio Sartor

 cervello è troppo gerarchico per accettare qualcosa del genere
Esatto.
I thread sono nati per avere multitasking con minimo
overhead, il che porta a tutta una serie di considerazioni
su quali compromessi fare tra robustezza e prestazioni.
Chiaramente vi saranno standard, immagino che questi
cerchino di dare qualche formulazione decente al
possible caos creato da questa idea di thread.
Tutto qua, ne` piu` ne` meno, direi che si puo`
discutere per secoli su come implementare un
oggetto chiamato "thread".
bye,
-- 
  Piergiorgio Sartor

migliore nella maggior parte dei casi
Che i thread siano nel 99% dei casi usati a sproposito e` un altro
discorso.
-- 
ciao, | "You're one of those condescending Unix computer users!"
Marco | "Here's a nickel, kid. Get yourself a better computer"  -- Dilbert
      | (Ri)scoprire fidonet: 
http://bbs.bofh.it

*brivido*
Solo se il processo in questione non e' il tuo >:->


quella per raggiungere l'illuminazione :-)
Bah, ho deciso  che certe cose in  vita mia non le  tocchero' mai: I
cavolfiori, i db e la "programmazione concorrente / distribuita" :)


 a win 98 c'era il dos a gestire tutto,
Guarda che anche il ME viene gestito ancora attraverso un sottostrato
dos
Henryx
-- 
Hey, EMACS is a nice OS, but Unix has a better editor ;-)
                -- Tim Ottinger

 cavolfiori, i db e la "programmazione concorrente / distribuita" :)
Devo dire che, nonostante mi trovi in parte d'accordo con te,
credo si debba (entrambi) ripensarci su:
1) I cavolfiori prevengono i tumori dell'intestino.
2) I DB sono gli applicativi piu` diffusi, hanno
guadagnato estrema importanza nella "internet era".
3) La programmazione concorrente/distribuita e` la chiave
per risolvere problemi normalmente irrisolvibili (tipo vincere
il premio della RSA).
Come vedi la natura delle cose complotta contro di noi!!! :-)
-- 
  Piergiorgio Sartor

esecuzione, tutto qui
Infatti, ed e' proprio il motivo per il quale quei modelli di
multithreading sono piu' limitati di quello di Linux.


questo thread o tutti gli altri? A me questi thread sembrano tanto dei 
Il problema e` che tu sei un ignorantello a cui piace pontificare su
cose che non conosce. Per la precisione:
       flags may also be
       bitwise-or'ed   with  one  or  several  of  the  following
       constants, in order to specify what is shared between  the
       parent and child processes:
       CLONE_VM
              If  CLONE_VM  is  set,  the  parent  and  the child
              processes  run  in  the  same  memory  space.
[...]
       CLONE_FS
              If  CLONE_FS  is  set,  the  parent  and  the child
              processes share the same file  system  information.
[...]
       CLONE_FILES
              If  CLONE_FILES  is  set,  the parent and the child
              processes share the  same  file  descriptor  table.
[...]
       CLONE_SIGHAND
              If CLONE_SIGHAND is set, the parent and  the  child
              processes  share the same table of signal handlers.
[...]


su quali compromessi fare tra robustezza e prestazioni.
Provo a proporre un diverso punto di vista: i thread sono un modello di
programmazione in cui un unico programma ha piu` flussi di esecuzione.
In altre parole, i thread sono un aiuto per chi non e` capace di
costruire una macchina a stati (che non necessariamente e` una
operazione sempre facile e sempre realizzabile).
Per realizzare una cosa simile pero` diventa necessario ridurre
notevolmente l'overhead dei context switch tra un flusso e l'altro, e
questo lo si fa proprio condividendo il contesto (cioe` cose come lo
spazio di indirizzamento, i segnali, i file aperti, eccetera).
A questo punto nascono cose come i LWP di solaris, che non sono processi
ma non sono nemmeno i thread di pthread, e nascono dall'impossibilita`
di affidarsi alla normale architettura usata per implementare i
processi, che in questo caso e` troppo lenta.
Lo stesso vale per i thread di NT, i cui tempi di context switching sono
geologici.
Un altra implementazione possibile e` un banale task switching
all'interno dello stesso processo, tutto realizzato in user space, che
pero` ha diversi problemi risolvibili solo con un aiuto dal kernel.
La soluzione di linux invece e` quella di generalizzare i processi
mediante clone(2), che permette di creare processi figli che condividono
determinate risorse con il padre, fino al caso limite in cui non viene
condiviso niente e in pratica si reimplementa fork(2) in user space.


 operazione sempre facile e sempre realizzabile).
Non sempre, a volte puo` essere utile risolvere un
problema in modo "parallelo", nella speranza di
far funzionare il SW su di una macchina parallela!
Considera un SW tipo Photoshop o Matlab, aver un design
multithreading (od anche multitasking, ma non sempre questo
e` altrettanto conveniente) fa si che le prestazioni possano
essere notevolmente aumentate nel caso in cui l'utente
abbia voglia e denaro per passare ad una macchina
multiprocessore, ma non essere troppo degenerate nel caso di
una macchina singolo processore.
Discorsi simili possono valere anche per applicazioni server.
Da notare l'importanza fondamentale dell'OS in questo
contesto, in teoria (e direi anche in pratica) si potrebbe
fare multithreadindg in clustering in modo totalmente
trasparente all'utente.
Con indubbio vantaggio di avere un sistema altamente
scalabile e soprattutto _facilmente_ scalabile.
Infatta basta comprare un altro PC ed attacarlo alla rete...
bye,
-- 
  Piergiorgio Sartor

trasparente all'utente.
E buttare le prestazioni nel cesso visto che il programma non e`
ottimizzato per una architettura enormemente NUMA.
Le architetture di clustering a shared memory funzionano *molto*
raramente con prestazioni decenti.


 raramente con prestazioni decenti.
Dipende anche qui, considera un SW tipo Lightwave, dovendo
fare rendering di filmati, cioe` di sequenze di frame, e`
sempre possibile e raccomandabile usare clustering.
L'idea del multithreading in questo contesto e` la seguente:
io scrivo il mio SW multithreaded e mi affido all'OS.
Se questo SW gira su una macchina SP, le prestazioni saranno
piu` o meno le stesse di un SW monolitico.
Se gira su una macchina MP, sfruttero` bene l'architettura.
Se gira su di un sistema a cluster, se l'OS supporta questo
e se il SW e` scritto avendo pensato un pochino su, girera`
ancora meglio in questo caso. Certo non si deve pensare, come
giustamente scrivi, ad avere shared memory su clustering,
ma in questo specifico caso il multithreading e` usato solo
per rendere il sistema scalabile, non per sfruttare le
possibilita` di condivisione di risorse dei thread.
bye,
-- 
  Piergiorgio Sartor

possibilita` di condivisione di risorse dei thread.
Allora non c'e` necessita` di usare thread, potrebbero benissimo essere
processi multipli. CVD (nel 99% dei casi i thread sono usati a
sproposito).


 sproposito).
No, perche` nel caso singola CPU e` meglio avere thread,
che non processi ed a volte e` meglio avere piu` di un "task"
contemporaneamente (magari non nel caso di Lightwave).
bye,
-- 
  Piergiorgio Sartor

stesso a livello di binario.
No. I problemi sono radicalmente diversi, non solo tra SMP e cluster, ma
anche semplicemente tra SMP normale e NUMA.


 anche semplicemente tra SMP normale e NUMA.
Appunto, per questo ti affidi all'OS.
L'OS dovrebbe decidere come realizzare il richiesto
multithreading, se con thread veri oppure con
processi eventualmente distribuiti.
Capisco che tu vuoi dire: "ma l'OS non sa con che testa
il programma e` scritto, per cui non potra` ottimizzare
per questo o quell'altro caso."
In questo senso chi scrive il programma deve aver capito,
a sua volta, quali siano le implicazioni delle varie
scelte, cioe` non potra` affidarsi ciecamente ai thread
ed in questo potrei darti ragione: spesso si usano soluzioni
(i thread, in questo caso) a sproposito.
Chiaramente la soluzione non e` banale e credo che piu`
di qualcuno ci stia ancora lavorando sopra, ma non
metterei limiti alla provvidenza :-)
bye,
-- 
  Piergiorgio Sartor

per questo o quell'altro caso."
No. Intendo dire che se ti interessano le prestazioni un programma non
puo` essere scritto allo stesso modo per funzionare sullo stesso
processore, sulla stessa macchina (c'e` differenza!) o su un cluster.


 processore, sulla stessa macchina (c'e` differenza!) o su un cluster.
Se ti serve il top in prestazioni, devi sapere questo ed
altro, ma allo stesso tempo realizzi un SW troppo specifico.
L'idea e` avere un buon compromesso tra "scalabilita`"
e prestazioni.
E non dico mica che sia facile od assolutamente trasparente,
dico solo che e` possibile concepire degli approcci suff.
generici, scalabili e "prestanti".
Il multithreading puo` o potrebbe aiutare in questo.
Con il supporto di un buona implementazione e tutto il
resto, incluso l'applicativo.
Ad ogni modo, ripeto, nessun meccanismo automatico puo`
(mai potra`) rimpiazzare l'abilita` del programmatore,
specie se interessano le prestazioni...
bye,
-- 
  Piergiorgio Sartor

multithreading sono piu' limitati di quello di Linux.
limitati? scusa, cosa mi permetterebbe di fare la nostra cara amica, la 
funzione clone, oltre a permettermi di spararmi allegramente in un 
piede? Io non vedo nessun vantaggio, a parte una terribile confusione 
tra processi veri e propri e thread (io voglio poter avere l'assoluta, 
adamantina, cristallina certezza matematica che un thread ha sempre e 
comunque pieno accesso all'intero heap, non un solo byte escluso. Solo 
allora esclamerò "Ecce thread!", non un solo compromesso prima), e una 
pervasiva presenza dell'I/O anche a questo livello (è... è... sbagliato!  
non c'è alcuna garanzia che esista I/O su questo sistema operativo! non 
si può presupporlo a priori! non è affatto scontato! gesù gesù, questo è 
il genere di cose che non mi ci vuole proprio alle sei del mattino)