Like the title.
Like the title.
"Se proprio devono piratare, almeno piratino il nostro." (Bill Gates)
"Non è possibile che 2 istituzioni statali mi mettano esami nello stesso giorno." (XWolverineX)
http://xvincentx.netsons.org/programBlog
Spesso si presenta il caso di voler eseguire più operazioni contemporaneamente , si ha cioè la necessità che una funzione del nostro programma venga svolta in parallelo alle altre . Non ci serve un task diverso, che anzi sarebbe controproducente in quanto, avendo dati separati, non consente un'agevole comunicazione con le altre funzioni . In questo caso utilizzeremo un thread, chiamato talvolta lightweight process o LWP , che appunto è una forma di multitasking leggero, attuato all'interno di un singolo task .
Quindi con i Thread puoi eseguire due azioni contemporaneamente. Se ho capito bene i thread rappresentano il modo per sfruttare al 100% le nuove potenzialità dei processori dual core, giusto?
Avete qualche piccolo esempio?
"Se proprio devono piratare, almeno piratino il nostro." (Bill Gates)
"Non è possibile che 2 istituzioni statali mi mettano esami nello stesso giorno." (XWolverineX)
http://xvincentx.netsons.org/programBlog
Attenzione, non e' detto che con un thread sia eseguito "in parallelo", cioe' in reale contemporaneità, con un altro thread nel caso dei dual core o dei multiprocessori.Originariamente inviato da XWolverineX
Quindi con i Thread puoi eseguire due azioni contemporaneamente. Se ho capito bene i thread rappresentano il modo per sfruttare al 100% le nuove potenzialità dei processori dual core, giusto?
Avete qualche piccolo esempio?
Anzi, per la maggior parte delle volte, cià non accade o molto limitatamente e dipende da tanti fattori molto difficilmente prevedibili.
Nel caso in cui si abbia un solo processore, ovviamente, questo esegue sempre un thread alla volta e quindi la "contemporaneità" è solo apparente.
Bisogna ricordare che, quando il sistema crea un processo, crea automaticamente anche il thread principale del processo che viene immediatamente eseguito.
La funzione di libreria di Windows che si occupa della creazione dei thread è la CreateThread (o se usi le MFC usi la AfxBeginThread) ci cui ti consiglio di leggere le specifiche in
http://msdn.microsoft.com/library/de...eatethread.asp
Bhe a quanto scrivi i threads non servono proprio a niente.
Se non funziona il loro scopo principale come vengono utilizzati?
"Se proprio devono piratare, almeno piratino il nostro." (Bill Gates)
"Non è possibile che 2 istituzioni statali mi mettano esami nello stesso giorno." (XWolverineX)
http://xvincentx.netsons.org/programBlog
Dove ho scritto che non servono a niente? Non l'ho mai detto.Originariamente inviato da XWolverineX
Bhe a quanto scrivi i threads non servono proprio a niente.
Se non funziona il loro scopo principale come vengono utilizzati?
La CPU e' unica e quindi la contemporaneità "deve" essere apparente.
Un sistema multiprocesso sfrutta meglio il processore disponibile (in quanto non tutti i processi sono sempre pronti per essere eseguiti, per tante ragioni). Ma uno switch di contesto per un processo e' molto pesante, al contrario di uno switch di contesto per un thread. Ecco quindi che un thread e' consigliabile.
Mettiamo che per esempio con un programma devi scaricare delle pagine da Internet. Queste pagine però sono in PHP, quindi il "collo di bottiglia" non è la CPU e nemmeno la connessione ad Internet, ma la velocità di risposta del server. Allora puoi fare 10, in modo da richiedere 10 pagine contemporaneamente alla volta e metterci 1/10 del tempo. Hai mai visto i download manager che fanno il segmented download ? Il principio è quello. In alcuni casi (non sempre) il multithreading ti permette di eliminare colli di bottiglia. Aggiungo: il multithreading è naturalmente indispensabile quando si devono avere processi paralleli che non interferiscono con il processo corrente: un'applicazione classica sono i timer.
Come hai già capito dalle ottime spiegazioni di Oregon e king, i Thread sono la soluzione "leggera" per implementare la concorrenza.
Come tutti i servizi forniti dal sistema operativo, dobbiamo capire se ci servono oppure no in base allo scenario in cui lavoriamo.
Se, per esempio, sto scrivendo un simulatore che sfrutta al 100% la CPU tutto il tempo e non effettua altro che calcoli (a parte l'Input iniziale) mi conviene senza dubbio effettuare una simulazione per volta per volta.
Se invece devo scrivere un videogioco in cui c'è una azione continua la quale scorrerebbe anche senza input (ma ne può venire influenzata, come un Rally) ecco che potrebbero servirmi i Thread.
Io, per esempio, ho programmato un giochino con una input machine in parallelo alla funzione che genera la schermata mediante Thread.
Aggiungo qualcosina in più alla teoria giusto per evitarti di andare a prendere un libro in biblioteca apposta.
I sistemi operativi usano i Thread in una delle due modalità possibili: user threads e kernel threads.
I kernel Threads sono visti dal sistema operativo come un'entità indipendente a cui può essere associato un time slice (un quanto di tempo di CPU), mentre gli user threads sono gestiti autonomamente dal processo che li ha generati senza che il sistema operativo sappia nulla della loro esistenza.
I threads condividono tra loro tutte le variabili a parte quelle di gestione (hanno un program counter separato, un ID separato ecc); bisogna porre particolare attenzione all'uso di variabili condivise perché l'uso concorrente potrebbe dare origine a errori che dipendo dall'ordine di schedulazione del SO.