[c threads] variabili locali/globali...

[AnonimoVeneziano]

Quello che succede è di semplice interpretazione.

Le variabili locali sono allocate nello stack.

Ogni volta che il thread termina semplicemente la cima dello stack viene spostata in alto in modo da non contare più lo spazio occupato dalle variabili locali del thread (che è molto simile ad una funzione). Non viene sovrascritto nulla. I valori sono ancora lì, solo che lo spostamento della cima dello stack fa in modo che per il programma siano cancellati.

Al momento dell'esecuzione del thread successivo la cima dello stack viene rispostata in basso per fare posto alla nuova variabile "x" del nuovo thread che, non venendo inizializzata, ha ancora il valore di quella del vecchio.

Probabilmente il valore sarebbe stato "veramente casuale" se l'esecuzione dei thread avvenissero veramente in contemporanea. (cioè ad esempio due o più thread vengono creati allo stesso tempo). Con molta probabilità questo non avviene. Questi thread sembrano essere molto rapidi da eseguire e più che essere eseguiti in parallelo vengono eseguiti in maniera seriale (come fossero delle funzioni, perchè un thread finisce prima che quello successivo sia stato creato) . La cosa si dovrebbe far sentire ancor di più su una macchina monoprocessore/monocore.

Ciao

[Gnappy]

Originariamente inviato da AnonimoVeneziano

Quello che succede è di semplice interpretazione.

Le variabili locali sono allocate nello stack.

Ogni volta che il thread termina semplicemente la cima dello stack viene spostata in alto in modo da non contare più lo spazio occupato dalle variabili locali del thread (che è molto simile ad una funzione). Non viene sovrascritto nulla. I valori sono ancora lì, solo che lo spostamento della cima dello stack fa in modo che per il programma siano cancellati.

Al momento dell'esecuzione del thread successivo la cima dello stack viene rispostata in basso per fare posto alla nuova variabile "x" del nuovo thread che, non venendo inizializzata, ha ancora il valore di quella del vecchio.

Probabilmente il valore sarebbe stato "veramente casuale" se l'esecuzione dei thread avvenissero veramente in contemporanea. (cioè ad esempio due o più thread vengono creati allo stesso tempo). Con molta probabilità questo non avviene. Questi thread sembrano essere molto rapidi da eseguire e più che essere eseguiti in parallelo vengono eseguiti in maniera seriale (come fossero delle funzioni, perchè un thread finisce prima che quello successivo sia stato creato) . La cosa si dovrebbe far sentire ancor di più su una macchina monoprocessore/monocore.

Ciao

Grazie anche a te per la tua competente risposta. Diciamo che anche questo "caso" l'avevamo analizzato. Sia io che dnarod siamo convinti che un difficilmente avverrà un context switch durante l'esecuzione di questo threads. Il problema è che questo progetto ci viene chiesto di testarlo con più threads simultaneamente(sleep inserite qua e la in modo da stopparne la computazione ed avere più di uno stesso thread contemporaneamente in esecuzione) e quindi questo "bug"(lol non ho idea di come definirlo) ci porta a meschiare queste variabili locali.

Invito anche te a leggere, se hai voglia s'intende, l'esempio che ho postato qui quotato come "Esempio con 3 threads che arrivano in maniera concorrenziale(conteporeaneamente)". Perchè questo è quello che abbiamo potuto simulare e toccare con mano testandolo direttamente sulla macchina.

[AnonimoVeneziano]

Originariamente inviato da Gnappy

No, non ci interessa. Questo int x lo usiamo per dimostrare che esiste una condivisione di variabili tra un thread e l'altro.


E' proprio qui la cosa bella, NOI VORREMMO CHE FOSSE COSI', ma nella realtà dei fatti NON E' COSI'


Possibile, è quello che stiamo pensando noi.. Ma come risolvere? Mettere dei mutex che lockano tutto il thread risolverebbe il problema ma andrebbe a perdersi tutta la concorrenzialità del progetto..


Si, ma come facciamo ad allocarlo "NON nello stesso punto dei precedenti"?
L'unico modo che ho di verificare che ogni thread che viene creato è diverso da un altro è controllare attraverso la pthread_self(che ritorna l'ID del thread). Abbiamo controllato e ogni thread è diverso da un altro.


Giusto, e sono d'accordo con te ma a questo punto il programma non funziona più in maniera concorrenziale. Qua ora, per semplicità stiamo usando una semplicissima variabile intera x. ma in questi threads noi dobbiamo lavorare su delle strutture e su una serie di variabili molto più ampia di un comune intero.
In ogni caso ti faccio una serie di esempi con questo codice nel thread:

void* ilnostrothread() {
  [...]
  int x = 0;
  sleep(2);
  x++;
  printf("%d\n", x);
  [...]
  pthread_exit(NULL);
}

Grazie anche a te per l'aiuto e la voglia di darci una mano

Sembra quasi come se lo stack venga scalato alla fine di un thread col risultato che il thread spawnato dopo va ad utilizzare il valore di "X" del thread precedente ...

Una cosa tipo :

1) il primo thread inizia , inizializza X a zero e ci somma 1, fa printf X , SWITCH
2) il secondo thread inizia, inizializza la propria X a zero (che sta sopra alla X del primo thread non ancora terminato) , SWITCH
3) il primo thread termina e lo stack viene ripristinato (facendolo crescere in modo da eliminare la variabile X del primo thread, ma in realtà viene eliminata quella del secondo thread che è quella in cima allo stack)
4) il secondo thread somma 1 alla X del primo thread (erroneamente) e la stampa a schermo, SWITCH
5) continua così anche con gli altri thread.

Potrebbe essere un possibile motivo del malfunzionamento .... anche se mi sembra un po' inverosimile.

Non sono un grande esperto di pthreads.

Ciao

[cionci]

I thread per definizione condividono lo spazio di indirizzamento del processo/thread che li crea. Quindi di qui non si scappa. Due thread concorrenti girano nello stesso spazio di indirizzamento, altrimenti non sarebbero concorrenti e la concorrenza dovrebbe essere stabilita tramite meccanismi di comunicazione interprocesso (vedi pipe, fifo, mailslot etc).

[Gnappy]

Già, è molto inverosimile ma qua siamo alla frutta, è da giorni che siamo fermi. Abbiamo ricompilato e riscritto da 0 codice per testare queste cose ma il risultato è quello..

Conosciamo il problema ma non sappiamo proprio come risolverlo, speriamo che a qualcuno venga una bella ideona, se no...

In ogni caso grazie per averci provato

[cionci]

Originariamente inviato da AnonimoVeneziano

Sembra quasi come se lo stack venga scalato alla fine di un thread col risultato che il thread spawnato dopo va ad utilizzare il valore di "X" del thread precedente ...

Ma questo è naturale ed avviene anche con le funzioni...se invece di richiamare quella funzione come un thread avrei lo stesso comportamento:

ilnostrothread(NULL);
ilnostrothread(NULL);

Molto probabilmente stamperebbe 1 e 2.

Nel codice che avete postato non c'è alcun malfunzionamento. E' semplicemente lo stato delle cose.

[AnonimoVeneziano]

Originariamente inviato da cionci

I thread per definizione condividono lo spazio di indirizzamento del processo/thread che li crea. Quindi di qui non si scappa. Due thread concorrenti girano nello stesso spazio di indirizzamento, altrimenti non sarebbero concorrenti e la concorrenza dovrebbe essere stabilita tramite meccanismi di comunicazione interprocesso (vedi pipe, fifo, mailslot etc).

Si, ma credo che almeno gli stack debbano essere separati. Mi sembra inverosimile che usino lo stesso stack.

Molto , molto strano

[cionci]

Originariamente inviato da Gnappy

Conosciamo il problema ma non sappiamo proprio come risolverlo, speriamo che a qualcuno venga una bella ideona, se no...

Io non ho ancora capito qual'è il problema...o meglio...come la questione vada ad influire sul vostro codice. Se influisce significa che non avete inizializzato delle variabili.

[Gnappy]

Originariamente inviato da cionci

I thread per definizione condividono lo spazio di indirizzamento del processo/thread che li crea. Quindi di qui non si scappa. Due thread concorrenti girano nello stesso spazio di indirizzamento, altrimenti non sarebbero concorrenti e la concorrenza dovrebbe essere stabilita tramite meccanismi di comunicazione interprocesso (vedi pipe, fifo, mailslot etc).

D'accordissimo, però tra le tante definizioni legate ai threads ce n'è anche una che dice(postata nel mio primo reply a questo argomento):

Le variabili che vengono dichiarate localmente all'interno della funzione che implementa il codice di ciascun thread sono private di quello specifico thread, e pertanto non accessibili da parte degli altri thread del processo.

E questo sembra non accadere.........

Boh, non avessi provato con le mie mani ogni caso, non avessimo riscritto da 0 codice apposta per fare tests, non fossi sicuro d'avere chiara la situazione e soprattutto non fossi sicuro d'aver scritto un codice senza bugs, non starei qui a whinare come una bestia.... LOL

[cionci]

Originariamente inviato da AnonimoVeneziano

Si, ma credo che almeno gli stack debbano essere separati. Mi sembra inverosimile che usino lo stesso stack.

Molto , molto strano

Gli stack sono separati. Sono istanze consecutive dello stesso thread...loro non fanno girare due thread contemporaneamente, ma ne fanno girare uno e poi ne fanno partire un altro quando il primo è terminato

[Gnappy]

Originariamente inviato da cionci

Io non ho ancora capito qual'è il problema...o meglio...come la questione vada ad influire sul vostro codice. Se influisce significa che non avete inizializzato delle variabili.

E' tutto spiegato qui nell'ultimo esempio: http://www.hwupgrade.it/forum/showpo...7&postcount=19
Meglio di così non riesco proprio a spiegarlo..

[cionci]

Originariamente inviato da Gnappy

E questo sembra non accadere.........

Non accade perché voi utilizzate istanze consecutive ed in quanto tali vanno a riutilizzare aree di memoria dove il thread precedente era allocato...

[Gnappy]

Originariamente inviato da cionci

Gli stack sono separati. Sono istanze consecutive dello stesso thread...loro non fanno girare due thread contemporaneamente, ma ne fanno girare uno e poi ne fanno partire un altro quando il primo è terminato

Si, nell'esempio banale della x non inizializzata, atto a dimostrare che esiste una INSPIEGABILE condivisione di variabili locali tra threads.
Come spiegato qui, nell'esempio "Esempio con 3 threads che arrivano in maniera concorrenziale(conteporeaneamente)" c'è un problema concorrenziale dal quale non riusciamo ad uscire.

[AnonimoVeneziano]

Forse ci siamo.

Dovete creare una variabile (nel main) di tipo "pthread_t" per ogni thread che volete lanciare in concorrenza

Quindi se volete mandare al massimo 10 thread contemporaneamente in esecuzione fate una cosa tipo :

pthread_t threads[10];

pthread_create(&threads[x], ....); <--- dove X è il numero del thread che volete lanciare.

Non riutilizzate sempre lo stesso.

Ciao

[Gnappy]

Originariamente inviato da cionci

Non accade perché voi utilizzate istanze consecutive ed in quanto tali vanno a riutilizzare aree di memoria dove il thread precedente era allocato...

No, attenzione. Ti sei focalizzato sull'esempio della x che abbiamo fatto all'inizio. Forse colpa nostra che l'abbiamo spiegato male, forse che cmq non è un argomento semplicissimo da debuggare, tantopiù attraverso un forum, questo non lo so.

Noi l'abbiamo fatto diversi test concorrenziali e il risultato è quello che ho scritto qui nell'ultimo esempio.

[Gnappy]

Originariamente inviato da AnonimoVeneziano

Forse ci siamo.

Dovete creare una variabile (nel main) di tipo "pthread_t" per ogni thread che volete lanciare in concorrenza

Quindi se volete mandare al massimo 10 thread contemporaneamente in esecuzione fate una cosa tipo :

pthread_t threads[10];

pthread_create(&threads[x], ....); <--- dove X è il numero del thread che volete lanciare.

Non riutilizzate sempre lo stesso.

Ciao

Eurekà! Mi fa piacere che qualcuno è riuscito a capire sto casino che ho messo in piedi, LOL..

Abbiamo provato ad adottare anche questa soluzione ma ci siamo bloccati per un "piccolo" motivo: quello che questo programma è un daemon sempre in esecuzione, come facciamo a creare un array finito di threads quando le richieste sono tecnicamente infinite? La soluzione "numero molto grosso" è troppo sporca ed inefficente ed è stata scartata.
Ma in ogni caso, se questa è effettivamente la soluzione al nostro problema dovremmo creare una lista di threads, ma poi, come la andiamo a gestire?

[dnarod]

nono spe, mi son perso un bel po di reply...grazie a tutti per le risposte innanzitutto....dunque, i thread creabili non sono in numero finito ne prederminabile in alcun modo; posso pensare che da questo stato di cose non sia facile uscire facilmente...va a finire che dovremo reinizializzare le variabili ogni volta e infilare l intero codice dei thread entro un mutex (cioe cio che ci hanno chiesto di non fare)...sinceramente non vedo altre soluzioni per evitare che qualcosa dentro un thread sia sporcata da qualcos altro di un altro thread...spero di essermi spiegato

[jappilas]

Originariamente inviato da cionci

x è locale a quell'istanza del thread...ogni thread ha la sua x che viene creata al momento della creazione del thread e distrutta al momento che la funzione del thread termina la sua esecuzione. In teoria gli altri thread potrebbero però accedere a x conoscendone l'indirizzo.

sì ma stando alla documentazione pare che GCC non consideri "automaticamente" le variabili dichiarate normalmente all' inizio della thread-loop function, come thread-local storage - che è quel che a loro serve dal momento che ogni thread deve avere la propria istanza completamente indipendente della variabile, in questo caso intera, x
e per istruire il compilatore all' uso del TLS sarebbe prevista una keyword apposita
__thread int x;

[tomminno]

Ma scusate potete postare un pezzo di codice reale in cui si manifesta questo problema?
Perchè se inizializzate tutte le variabili e dopo l'inizializzazione queste risultano corrotte ci deve essere un problema da qualche altra parte.

[cionci]

Non ho capito questo esempio:
SIMULAZIONE POSSIBILE:
1) creazione ilnostrothread_1.
2) inizio computazione ilnostrothread_1, int x = 0, sleep, context switch.
3) creazione ilnostrothread_2.
4) inizio computazione ilnostrothread_2, int x = 0, sleep, context switch.
5) creazione ilnostrothread_3.
6) inizio computazione ilnostrothread_3, int x = 0, sleep, context switch.
7) proseguimento computazione ilnostrothread_1, x++, x = 1, "1", pthread_exit.
8) proseguimento computazione ilnostrothread_1, x++, x = 2, "2", pthread_exit.
9) proseguimento computazione ilnostrothread_1, x++, x = 3, "3", pthread_exit.

Questo è quello che volete ottenere o quello che NON volete si ottenga ?
L'output in questo caso è ovviamente 1, 1, 1