Newsgroup: it.comp.os.dibattiti
Titolo: Thread e processi

Salve a tutti, perdonate la domanda da "profano" ma vorrei ben capire
qual'č la differenza tra un thread e un processo perchč mi risulta
abbastanza ostica. E poi č vero che processo e job sono piů o meno la
stessa cosa?
Vi ringrazio, mi togliereste un dubbio non indifferente :-)

 wrote in message
news:f57c1de5.0401...@posting.google.com

http://groups.google.com/groups?hl=it&lr=&ie=UTF-8&oe=UTF-8&threadm=fd5bdd3b517f6802b39178897dc66c75.58813%40mygate.mailgate.org&rnum=2&prev=/groups%3Fq%3Dthread%2Bgroup:*.win32%2Bauthor:paolitto%26hl%3Dit%26lr%3D%26ie%3DUTF-8%26oe%3DUTF-8%26selm%3Dfd5bdd3b517f6802b39178897dc66c75.58813%2540mygate.mailgate.org%26rnum%3D2
HTH
C:\>iao Angelo
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG



Non sono sicuro, ma credo che se quando crei un processo (forkando da uno
esistente), il nuovo processo č una copia esatta del precedente, quindi
tutto lo stato viene duplicato (le variabili vengono duplicate, per
intenderci).
Invece due thread di uno stesso processo condividono lo stato del processo
(accedono a quelle variabili come risorse condivise)
Magari č tutta una fesseria! :-)
-- 
Best Regards,
Maurizio Colucci
Please remove the uppercase letters "S,P,A,M":
seSgPuAsM...@tin.it

> Magari è tutta una fesseria! :-)
No no no hai ragione! grazie a tutti...

 abbastanza ostica. 
Un processo è un entità di programma che il sistema operativo identifica e 
può eseguire a se stante (spazi di memoria, privilegi, etc...). Il thread è 
in un certo senso il suo figlio minore, è indipendente solo per quanto 
riguarda il tempo di esecuzione mentre dipende per tutto il resto dal 
processo padre.

 intenderci).
Non e' completamente vero. Su Unix in generale un certo numero di
variabili sono condivise tra padre e figlio (i file aperti ad esempio).
La quantita' di informazioni condivise  (di solito)  e' controllabile
con i parametri di creazione del processo figlio. In casi estremi, con
gli opportuni parametri, processo padre e processo figlio sono
indistinguibili [1].
C:\>iao Angelo
[1] Caso Linux e la clone().


 processo padre.
Però saprai meglio di me che possono esistere processi figli... Che
però sono sempre processi! O diventano thread automaticamente? E'
questo il nodo che devo sciogliere :-)

+++++++++[<++++++++>-]<----.>+++++[<+>-]<.>++++[<-->-]<.>+++++[<++++>-]<.

 questo il nodo che devo sciogliere :-)
Per studio o per diletto?
bye,
-- 
   Piergiorgio Sartor

 variabili sono condivise tra padre e figlio (i file aperti ad esempio).
I file aperti non sono variabili, direi che sono delle capabilities.
Saluti.
-- 
\/               
wirix...@libero.it
          ICQ UIN: 3233084
/\ e l l o s s   (per rispondermi in privato, elimina il DEMONE)

questo il nodo che devo sciogliere :-)
Ridotto ai minimi termini:
I Thread sono "sottoprocessi": uno o più thread insieme concorrono ad
eseguire il compito svolto dal processo
I Processi Figli sono processi a tutti gli effetti, svincolati dal
padre e indipendenti
Esempi:
In un Word Processor puoi avere diversi Thread, ad esempio uno che
formatta il testo che digiti e uno che esegue la segnalazione degli
errori durante la scrittura; tuttavia il processo è unico, ovvero il
Word Processor.
I processi figli entrano in gioco, ad esempio, nelle shell: la shell
interpreta il comando e crea un processo figlio che esegue il comando
richiesto. Il nuovo processo è figlio della Shell, ma non è un suo
thread
--
INFINITO, LOOP: Vedi "Loop Infinito"
[...]
LOOP INFINITO: Vedi "Infinito, Loop"

> Per studio o per diletto?
All'inizio per studio (esame di sistemi operativi) ma anche per
diletto, mi sta appassionando la cosa. E poi ci sto tutti i giorni su
un S.O., perchè non dovrei conoscerlo? :-)

 un S.O., perchè non dovrei conoscerlo? :-)
Perche` a seconda del motivo cambia la risposta... :-)
In un SO multitasking, ogni task e` generato per una qualche
azione, tipicamente di un altro task (in Unix almeno, tranne
casi patologici, tipo "init").
Quando un task viene fatto partire, questo avra` delle risorse
allocate, tipo variabili d'ambiente, file (aperti), etc.
Possiamo distinguere due casi estremi, uno che chiameremo
"processo" ed uno che chiameremo "thread" (nota che i nomi
sono assolutamente arbitrari).
Nel caso del "processo", tutte le risorse allocate alla
partenza sono completamente *indipendenti* dalle risorse
del task padre (cioe` del task che ha fatto partire il
"processo").
Nel caso del "thread", tutte le risorse allocate alla
partenza sono *condivise* con il task padre (cioe` il
task che ha fatto partire il "thread").
Tra questi due estremi ci sta tutta una serie di possibili
compromessi su cosa sia indipendente e cosa sia condiviso.
La ragione per cui esistono queste variazioni e` che un
"processo" risulta piu` robusto, perche` *isolato*, ma
anche piu` oneroso da creare e gestire.
Un "thread", invece, e` piu` leggero, ma, ovviamente, un
pelo piu` delicato, dato che puo` influire direttamente
sulle funzionalita` del padre.
I vari possibili casi intermendi, aprono tutta una serie
di problematiche, sia implementative che filosofiche, ad
es. se un task chiude un file, cosa succede allo stesso
file aperto dal padre?
bye,
-- 
   Piergiorgio Sartor

 questo il nodo che devo sciogliere :-)
La parentela che esiste tra processi *parenti* per l'appunto, è solo
gerarchica, non esiste nassun legame diciamo *di sangue*. :)
Un thread è una intima creazione di un processo, è un suo filone esecutivo,
che dipende in modo quasi totale dal processo padre.
-- 
Qual è l'uomo che può conoscere un numero?

 perň sono sempre processi! 
Certo, ma il thread non ha solo la limitazione (rispetto al processo) di 
essere "figlio". Come ho detto, il thread ha un requisito base di avere un 
proprio "tempo CPU" per l'esecuzione in multitasking. Un processo č 
identificato e visibile al sistema operativo, il thread no.

 identificato e visibile al sistema operativo, il thread no.
Attenzione, dipende. 
Il supporto per i thread può essere fornito dal SO, che si accolla tutti gli
oneri ed i doveri della gestione dei sudetti, e che si preoccupa di
schedularli, oppure può essere implementato a livello di libreria utente. 
In quest'ultima circostanza il SO fornisce quanti di CPU ai processi (non
sapendo nulla dei thread), che si occupano di gestire i propri thread
tramite funzioni apposite. 
Esistono anche soluzioni ibride, dove per esempio il SO fornisce strutture e
logiche di gestione elementari, che vengono utilizzate da librerie utente
per implementare i thread.


 tramite funzioni apposite. 
Quindi per qualche SO non esistono a vista i thread... deduco allora
che siano gestiti creati distrutti (tutto d'un fiato) dai programmi
utente, giusto?

utente, giusto?
Esatto. prendi il Dos, ad esempio: č un OS monotasking, ma nulla ti
vieta di scriverci un programma multithreading, se hai la voglia e il
masochismo per farlo (devi preoccuparti non solo della creazione e
distruzione dei thread, ma anche della schedulazione degli stessi,
della sincronizzazione...)

 "processo").
In unix, dopo una fork, non abbiamo una copia del processo padre 
ereditante anche, ad esempio,
i files aperti dal padre? (perlomeno, se non sbaglio, fino al richiamo 
di "exec", per caricare
un altro programma)
bye G.L.
-- 
- Renaissance, aka Gian Luca Sole -
Cit. « E' assolutamente evidente che l'arte del cinema
  si ispira alla vita, mentre la vita si ispira alla TV »
                                         (Woody Allen)

 un altro programma)
Se abbiamo una copia, allora le risorse (file descriptor)
sono indipendenti.
In ogni caso non e` detto che il termini "processo" si
riferisca ai processi Unix.
bye,
-- 
piergiorgio

 riferisca ai processi Unix.
Certo, infatti ho specificato "in unix".    ;-)


 memoria allocata e cpu.
Da quello che mi ricordo si, fork() sdoppia il processo
che la invoca, creandone una copia identica, ma non mi
risulta che condividano nulla, tutto dovrebbe essere duplicato.
Da notare, pero`, che e` duplicato da padre a figlio,
cioe` i "valori" sono anche duplicati, per cui il
figlio si trova nello stesso identico stato del padre,
eccetto per il pid ritornato da fork() (e probabilmente
qualche condizione sui segnali).
In Unix questo, ovviamente uno puo` definire la procedura
come piu` gli pare, ad es. in certi OS la partenza di un
task e` definita su di una funzione, cioe` esiste qualcosa
come taskStart(funzione) e la "funzione" parte in modo
asincrono rispetto al chiamante e, dato che e` una funzione,
non condivide nulla che non sia esplicitamente condiviso.
Questa e` anche una variante sui thread, che in alcuni casi
sono proprio gestiti cosi`, ovviamente la cosa puo` anche
essere fatta con fork() e qualche linea di codice aggiuntivo:
...
func = puntatore_a_funzione;
if((pid = fork()) == 0) res = func();
...
In questo caso il problema potrebbe essere quello di ritornare
il risultato al padre, cosa che nei thread dovrebbe essere
naturale, mentre nei processi richiede un IPC esplicito.
bye,
-- 
   Piergiorgio Sartor

 memoria allocata e cpu.
Alt... Risorse distinte ma i file aperti non vengono riaperti... C'e`
una tabella di file aperti in unix e tutti i processi fanno richiesta
di aprire un file che poi l'OS apre e ritorna il suo fd con un pointer
alla tabella dei file aperti (appunto FILE *). Se fai 1000 fork viene
duplicato il puntatore al file aperto, non aperti 1000 file.
L'area di memoria viene perfettamente duplicata tranne per il pid. Ma
e` proprio UGUALE, uguali sono i settaggi dei registri e via dicendo
(stack, heap, library, codice e via dicendo), tutto questo ovviamente
1 istante dopo il fork, poi le vite del padre e figlio si separano per
sempre (sigh :) )
Tant'e` che:
from os import fork
fork()
while 1:
    print "ciao"
Crea 2 aree di memoria identiche che fanno esattamente la stessa cosa
e per le quali cambia solo il pid (che non e` detto mi interessi).
-- 
Valentino Volonghi, Regia SpA, Milan
Linux User #310274, Gentoo Proud User

 naturale, mentre nei processi richiede un IPC esplicito.
Sia pure non programmi in C... cio' mi e' chiaro, non condividendo il p. 
figlio niente con il p. padre.
(perlomeno in un contesto unix)


 L'area di memoria viene perfettamente duplicata tranne per il pid. 
Beh no, in genere la memoria codice non viene duplicata, ma rimane
condivisa. Finché ovviamente non si chiama la exec*.


 condivisa. Finché ovviamente non si chiama la exec*.
Non viene duplicata "fisicamente", dato che esiste la COW,
ma di fatto e` come se fosse doppia.
bye,
-- 
piergiorgio

 ma di fatto e` come se fosse doppia.
Se vuoi vedere la faccenda in questo modo, fai pure. Ma il codice è
read-only per cui non è realmente soggetto a copy on write.
Tra l'altro, non credo che la copy on write sia sempre esistita in tutti
gli unix, mentre sono convinto che la fork non abbia mai duplicato il
codice. Se mi sbaglio correggetemi :-).


 read-only per cui non è realmente soggetto a copy on write.
Scusa, ho saltato "codice"...
bye,
-- 
piergiorgio


Il copy on write si applica alla memoria scrivibile, non a quella  sola 
lettura, ed il codice risiede in memoria a sola lettura. Quindi, non 
viene duplicato, mai, se non "logicamente", a livello di memoria virtuale.
-- 
"Everything is vague to a degree you do not realize till you have tried
  to make it precise"
                                 |     Bertrand Russell
falemagn (AT) aros (DOT) org    |     The Philosophy of Logical Atomism

 viene duplicato, mai, se non "logicamente", a livello di memoria virtuale.
Fabio, all'unaetrenta??!!??
Stai cercando di vincere il premio "Get A life" 2004?
Comunque hai perfettamente ragione, come gia` scritto alle 12.45,
avevo saltato "codice", pensavo si riferisse ai dati.
bye,
-- 
piergiorgio

 Comunque hai perfettamente ragione, come gia` scritto alle 12.45,
Mi era sfuggito, scusa. 00:45 dici? Così lontanto da 1:30?


 Mi era sfuggito, scusa. 00:45 dici? Così lontanto da 1:30?
Appunto... ;-)
bye,
-- 
piergiorgio

 condivisa. Finché ovviamente non si chiama la exec*.
C'hai raggggione, ho fatto confusione.
