Newsgroup: it.scienza.informatica
Titolo: thread

Ciao a tutti,
sto cercando della documentazione sui Thread. Sapreste indicarmi degli
indirizzi di siti Internet che contengano delle informazioni al riguardo
?
Thanx in advance.
Giampaolo "mancho." Mancini

Indirizzi su internet non ne conosco, ti consiglio di cercare con altavista.
Se ti va di programmare con i thread in unix ti consiglio questo libro.
Graham Glass: Unix for users and programmers, Prentice-Hall
-- 
# Giorgio Vecchiocattivi.
# Dip. Informatica, Universitá di Pisa. 

 indirizzi di siti Internet che contengano delle informazioni al riguardo
Per Linux: 
http://pauillac.inria.fr/~xleroy/linuxthreads/
-- 
Davide   |`. /\      
albe...@usa.NO-SPAM.net
      | PGP KeyID:
Alberani |__)~~\ 
http://members.xoom.com/alberanid/
 | 0xD0354739

Un bel di' G.Vecchiocattivi scrisse:
GV> 
GV> Indirizzi su internet non ne conosco, ti consiglio di cercare con altavista.
GV> Se ti va di programmare con i thread in unix ti consiglio questo libro.
GV> 
GV> Graham Glass: Unix for users and programmers, Prentice-Hall
GV> 
Scusate... tanto per farmi un po' di cultura e per aumentare le domande 
in questo NG... cosa sono i thread??
O meglio: cosa si intende per programmare con i thread?? :-)
-- 
"Quando un sistema arriva ad essere completamente definito, qualche
maledetto idiota scopre qualcosa che annulla il sistema o che lo espande
fino a renderlo irriconoscibile", legge di Brooke
-- 
Emanuele Cesena
d.a.m...@iol.it
    occhio all'antispam NOSPAM!
http://www.geocities.com/SiliconValley/Grid/8879

 -- 
Dunque, un thread e' un "processo leggero", ossia che condivide il proprio
spazio di indirizzamento con altri thread (di privato ha solo la pila).
La programmazione con thread e' puo essere vista come un modo di avere
piu' punti di esecuzione di un programma. Ossia lo stesso programma viene
eseguito parallelamente in piu' punti in varie routine, l'esempio che
viene bene a capire e' un programma che per esempio comunica sulla rete
e contemporaneamente disegna delle immagini sullo schermo (e indovinate
di cosa parlo :) ).
La differenza tra il concetto di "processo" e "thread" e' nello spazio
di memoria. Due processi diversi comunicano attraverso condivisione
di porzioni di memoria che viene controllata con espliciti meccanismi
di protezione, per cui quando il processore sospende un processo e ne
mette in esecuzione un altro deve ripristinare (oltre ai registri) la
tabella dei diritti di memoria del processo, questo puo' essere "costoso".
Un thread invece quando viene messo in esecuzione dopo un thread della
stessa famiglia puo' evitare questo (i diritti di accesso alla memoria
sono gli stessi) e quindi risparmiare qualcosa di calcolo.
In pratica i sistemi operativi vedono i thread come sotto processi, ossia
un processo puo' essere suddiviso in piu' thread. Ci sono 2 scheduler,
uno gestisce il tempo del processore tra i processi, e ogni processo
suddivide il proprio tempo tra i propri thread.
La programmazione con thread e' oggi alla moda grazie a Windows della
Microsoft, la quale non essendo capace di fare un sistema operativo con
processi ha fatto un sistema operativo con thread soltanto (o task come
li chiamavano ai tempi di win3). Ora il problema e' che un se si inchioda
un thread (se funziona male o scrive in memoria dove non deve),
blocchera' il funzionamento di tutti i thread della sua famiglia (ossia
del suo processo)... piu' sono le funzionalita' gestite dal processo
e peggio e' (
p.es
. tutta l'interfaccia grafica di Win95 e' un unico
processo, con tutte le finestre delle risorse).
Programmare con i thread sembra facile, in realta' e' facile
programmarci male. Se l'applicazione e' compicata, sincronizzare i
thread tra loro diventa difficile e critico, e' molto piu' facile il
meccanismo di scambio messaggi tra i processi.
Ultima considerazione un programma multithreading non scala, ossia e' 
"fortemente" inadatto a architetture multiprocessore.
Ah... mi sono sfogato... adesso mi vado a prendere un caffe' (non di
marca java)


marca java)
Alla tua salute.
Antonio Donatiello

Un bel di' G.Vecchiocattivi scrisse:
GV> Dunque, un thread e' un "processo leggero", ossia che condivide il proprio
GV> 
Grazie mille dell'ottima spiegazione... e grazie ad Antonio per la replica...
seguiro' il dibattito che sembra nascere... purtroppo difficilmente potro'
parteciparvi :-)
Grazie mille ancora! :-)
(e scusate il mio TIN... non si riferisce certo a voi!) :-)
-- 
"Non discutere mai con un idiota: la gente potrebbe non notare la
differenza", prima legge del Dibattito


processore diverso.
Non intendevo questo. Intendevo che un programma "multithreading" e'
intrinsecamente legato a una visione dell'architettura a memoria
condivisa. Quindi su macchine a memoria distribuita in generale
"non si puo' fare" efficentemente. (A parte simulando una memoria
condivisa, che di solito e' appunto (molto) inefficente, ma qualche
volta riserva strane sorprese).
Su macchine a memoria condivisa pero' scala male, ossia aumentando
il numero di processori l'efficenza peggiora, dopo un po' ci si accorge 
che mediamente il numero di processori che lavora si stabilizza e non
amuenta
piu'. (Gli altri processori rimangono bloccati su lock di memoria)
Per efficenza diciamo che si puo intendere il tempo in percentuale che
un processore
passa in attesa (attiva) di accedere alla memoria.
Se poi ci vogliamo fare un sistema operativo, piu' di un paio di
processori
(diciamo 4?) non si possono mettere insieme. (winnt ne mette su al
massimo due
mi pare, e francamente per quello che ho visto sono rimasto molto
deluso.)
Buona notte.


deluso.)
Windows NT server supporta 4 processori. Non ho test personali ma mi ricordo
che in test di riviste specializzate generalmente Windows NT esce molto bene
come application server.
Ma questa e' un'altra storia...
Ciao e grazie per il dibattito.
Antonio Donatiello

 ignoro!)
La causa è solo la cattiva abitudine; in realtà il multithreading dovrebbe
largamente essere gestito mediante messaggi (lasciando le interazioni "dirette"
solo ai processi "paralleli" della stessa classe).
saluti,
	Denis

Ma anche i processi di Unix hanno bisogno di memoria condivisa. O no?
A voglia... Chiariamoci che quando parlo della comunicazione di
processi non mi riferisco a quella sotto unix "classici". La memoria
condivisa e' un problema che gli Unix "classici" si portano dietro
come un macigno... In pratica di condiviso c'e' tutto il nucleo del
s.o. .  Infatti gli Unix "classici" sono profondamente inadatti a
macchine multiprocessore con memoria condivisa, e impensabili per
macchine a memoria distribuita. 
Negli ultimi anni si stanno sviluppando sistemi Unix a nucleo minimo,
adatti per girare su multiprocessori a memoria condivisa (multi vuol
dire 10-100 processori). Il nucleo minimo (condiviso) contiene in
pratica solo il supporto per le primitive di comunicazione tra
processi (solo scambio di messaggi) e lo scheduler per i processi. 
WinNt e Unix sono molto simili sotto questo punto di vista, su piu' di
pochi processori non possono andare per problemi di eccessiva memoria
condivisa (che va eseguita in modalita' di lock! come e' quella del
s.o)
Buon Natale! 
G.Vecchiocattivi

giorno all'altro).
Beato te. Comunque la teoria della fermentazione e' interessante, e
credo che si possa allargare a molti campi dell'informatica.
Giorgio.

Come funziona la creazione di nuovi processi (o task) in windows?
In Win32 si sono 2 funzioni: CreateProcess() e CreateThread().
Con la prima si manda in esecuzione un altro.
Con la seconda si manda in esecuzione la funzione passata come puntatore.
Antonio Donatiello

Con la prima si manda in esecuzione un altro.
volevo dire:
Con la prima (CreateProcess) si manda in esecuzione un altro PROGRAMMA.
Chiedo scusa.
Antonio Donatiello