[C] Chiarimento sui thread ed esecuzione parallela

[Poker1]

Ciao a tutti!!!
Ho appena iniziato a studiare i thread posix. Ecco il codice:

static void funz()
{
while( true )
printf( "Sono il thread 2");
}

int main()
{
pthread_t tid;

pthread_create( &tid, NULL, &funz, NULL );

while( true )
printf( "Sono il thread 1" );

return 0;
}

lui crea il thread, poi entra nel while del main, scrive
Sono il thread 1
poi va ad eseguire la funzione e scrive
Sono il thread 2

non ho ben capito il motivo. Li ho messo un while infinito, perche' esce per andare ad eseguire l'altro thread e cosi' via? Cioe', il motivo puo' anche essermi chiaro, ma non ho capito come faccio a determinare il momento in cui un thread abbandona la sua azione per chiamarne un altro...

grazie!

[oregon]

No ... un attimo, non e' il thread1 che "abbandona" il while per eseguire l'altro thread ...

I due thread (ovvero i due cicli) sono eseguiti contemporaneamente ... quello che e' attivo in un certo momento e' determinato dal sistema operativo, dal suo scheduler ...

[Poker1]

Ah, e' come se fossero eseguiti in parallelo?

[oregon]

Sì ... altrimenti a cosa servirebbero i thread?

[Poker1]

hem..non lo so hehe..li sto studiando adesso :P:P
per questo non avevo campito il funzionamento..

[ibykos]

Una cosa importante: in Unix è più saggio usare i processi piuttosto che i thread per ottenere la concorrenza.
Windows di solito garantisce migliori prestazioni rispetto ai sistemi Unix e derivati perché nei suoi apllicativi si fa uso prevalentemente di thread; la cosa comporta degli svantaggi in termini di stabilità, di facilità di debugging e di protezione dei dati, tutti punti di forza di Unix, di cui i suoi fautori vanno molto fieri :-)
ciao!

[oregon]

Scusa ibykos, ma sono parzialmente d'accordo ...

Con Windows e' *sempre* possibile utilizzare la concorrenza con i processi piuttosto che con dei thread ... in questo modo tutti i vantaggi di cui parli esistono anche con Windows ...

Alcuni di questi "vantaggi", peraltro, non sempre sono cosi' evidenti ...

Fare il debug di una applicazione "multiprocesso" (che avvia piu' di un processo e che li fa comunicare tra loro) non e' che sia molto piu' semplice di fare il debug di un'applicazione multithread!

Per quanto riguarda la stabilita' (e la protezione dei dati ...), sicuramente si "paga" il fatto che i thread lavorino sullo stesso spazio di indirizzamento, ma in genere questa e' *proprio* il vantaggio dei thread per cui viene scelta tale soluzione ...

Quindi, non per iniziare la solita discussione, ma c'e' chi va fiero anche del core di Windows ...

[ibykos]

Sarebbe una bella discussione, in ogni caso io alla fine sono passato a Windows e sono convinto che offra un'infinità di vantaggi in più rispetto a Unix.
Non intendevo iniziare una guerra di religione, ma solo mostrare il fatto che in windows molti programmatori preferiscono usare i thread piuttosto che i processi per realizzare la concorrenza, mentre nel mondo Unix avviene esattamente il contrario.
Mi sono infilato nel tunnel dell'OT (mea culpa, mea maxima culpa ) e preferirei uscirne senza lasciare spazio a chi gode a distruggere discussioni come questa.
Poker1, prova sia a libreria pthread.h e le varie funzioni di gestione dei processi di unix

fork
vfork  //forka senza salvare tutto, utile se si usa la exec
signal //registra un signal handler
kill   // invia un segnale ad un processo
exec** // la famiglia delle funzioni che cambiano vita 
       // al processo

E decidi tu con cosa ti trovi meglio.

[oregon]

No .. nessuna guerra di religione ... in fondo siamo d'accordo ...

Volevo solo precisare che la preferenza dei thread deriva dal fatto che, la maggior parte delle volte, l'utilizzo di piu' processi non e' giustificato da esigenze di progetto mentre i thread rendono piu' "leggera" l'applicazione ...

Nonostante cio', e' sempre possibile con Windows realizzare un'applicazione con piu' processi concorrenti ... ecco, non vorrei far passare l'idea che con Unix si puo' lavorare con piu' processi mentre con Windows no e si rendono obbligatori i thread ... sono scelte di progetto.

Ciao e buon lavoro

[Poker1]

Sto studiando tutte queste cose all'universita' e quindi "vado dietro al gruppo". Abbiamo fatto i processi ( fork, exec, wait ) diciamo molto velocemente, adesso siamo guardando i thread..poi passeremo alle Pipe, semafori e socket. Questi ultimi mi sono decisamente oscuri e alla fine non so se il progetto che dobbiamo fare ( chat ) faccia piu usi di processi o di thread.
L'unica cosa che so adesso e' che i thread mi sono piu semplici da usare, i processi con questa fork() mi fanno incasinare decisamente, magari col tempo sapro' usarli meglio ma per ora..vado dietro al branco