Torna indietro   Hardware Upgrade Forum > Software > Programmazione

Samsung Galaxy S25 Edge: il top di gamma ultrasottile e leggerissimo. La recensione
Samsung Galaxy S25 Edge: il top di gamma ultrasottile e leggerissimo. La recensione
Abbiamo provato il nuovo Galaxy S25 Edge, uno smartphone unico per il suo spessore di soli 5,8 mm e un peso super piuma. Parliamo di un device che ha pro e contro, ma sicuramente si differenzia dalla massa per la sua portabilità, ma non senza qualche compromesso. Ecco la nostra prova completa.
HP Elitebook Ultra G1i 14 è il notebook compatto, potente e robusto
HP Elitebook Ultra G1i 14 è il notebook compatto, potente e robusto
Pensato per il professionista sempre in movimento, HP Elitebook Ultra G1i 14 abbina una piattaforma Intel Core Ultra 7 ad una costruzione robusta, riuscendo a mantenere un peso contenuto e una facile trasportabilità. Ottime prestazioni per gli ambiti di produttività personale con un'autonomia lontano dalla presa di corrente che permette di lavorare per tutta la giornata
Microsoft Surface Pro 12 è il 2 in 1 più compatto e silenzioso
Microsoft Surface Pro 12 è il 2 in 1 più compatto e silenzioso
Basato su piattaforma Qualcomm Snapdragon X Plus a 8 core, il nuovo Microsoft Surface Pro 12 è un notebook 2 in 1 molto compatto che punta sulla facilità di trasporto, sulla flessibilità d'uso nelle differenti configurazioni, sul funzionamento senza ventola e sull'ampia autonomia lontano dalla presa di corrente
Tutti gli articoli Tutte le news

Vai al Forum
Rispondi
 
Strumenti
Old 06-11-2007, 11:33   #1
dnarod
Senior Member
 
L'Avatar di dnarod
 
Iscritto dal: Nov 2002
Messaggi: 4329
[c threads] variabili locali/globali...

ho un programma che crea piu thread...nel codice di uno di questi (per prova) ho scritto:

int x;
x++;
printf("%d\n", x);

nel main creo una variabile p_thread e creo due volte, una di seguito all altra, il thread e la prima volta stampa 1, la seconda 2...wtf? ma la cosa piu bella:
-creo un thread (con quelle 3 righe)
-subito dopo un altro thread che non contempla neanche l esistenza di x
-creo un altro thread dello stesso tipo del primo
-stampo x e mi da un valore negativo immenso (penso min intero)

buh, la morale e che a me serve avere delle variabili dichiarate all interno del codice di un thread e alle quali abbia accesso solo quel thread e non qualsiasi altra fregnaccia...si puo fare? come? grazie in anticipo
__________________
|18k+|slk800|a7n8x|1Gb/ddr400|Gf4mx440|Pio108|WD 160Gb|Case|Uni|Album|AnimeClick|OneManga|
|ClassicThrash!|BNR Metal|TrueMetal|Dime|Chuck|
dnarod è offline   Rispondi citando il messaggio o parte di esso
Old 06-11-2007, 13:38   #2
Gnappy
Member
 
Iscritto dal: Feb 2001
Città: Nelle Langhe, dove non c'è tecnologia ma solo buon vino
Messaggi: 154
Mentre faccio un up espongo meglio il problema in quanto dnarod, a forza di vedere solo codice, si e' dimenticato l'italiano....

Il programma in questione e' un daemon che rimane in esecuzione in un sistema in attesa di richieste da parte di vari clients che concorrenzialmente lo andranno ad interpellare.
Senza andare troppo nel dettaglio, inutile, ad ogni richiesta questo daemon lancia un programma figlio, nella fattispecie un nuovo thread, che si occupera' di questa richiesta in modo che il programma padre possa rimettersi nuovamente, ed immediatamente, in "ascolto" di nuove richieste.
Il nocciolo del problema e' che per assicurare la concorrenzialita' tra i processi di questo sistema non possiamo far uso del classico pthread_join(che consiste nell'aspettare la terminazione del thread 'x') nel daemon. In questo modo la concorrenzialita' tra i processi viene mantenuta e con il corretto uso dei mutex viene anche mantenuta la mutua esclusione nelle sezioni critiche di ogni thread lanciato.
Fin qua sembra che abbiamo capito tutto e che il programma possa funzionare senza problemi, PERO' durante l'esecuzione abbiamo notato che alcune variabili, dopo un paio di threads lanciati, risultavano "sporche" e qui si riconduce il post di dnarod:
Quote:
Originariamente inviato da traduzione dal post di dnarod
Abbiamo aggiunto nel codice di un thread per prova una variabile intera x, l'abbiamo incrementata e successivamente stampata:
Codice:
int x;
x++;
printf("%d\n", x);
A questo punto siamo andati a testare il programma lanciando il daemon ed inviando l'opportuna richiesta per far lanciare il thread con quel pezzo di codice.
Alla prima chiamata verra' printato "1". Alla seconda chiamata dello stesso thread verra' stampato "2".
Ad una prima e disattenta analisi questo puo' anche sembrare "giusto", pero' l'intero x dichiarato e creato nel primo thread DEVE(a rigor di logica ed a meno che non ci sfugge qualcosa) essere per forza diverso dall'x dichiarato e creato nel secondo thread e SOPRATTUTTO non puo' essere condiviso e TANTOMENO incrementato dal thread successivo.
Ragionando sulla questione abbiamo pensato(in maniera del tutto ignorante) che sbagliamo a creare i threads ed entrambi sono lo stesso thread. Siamo quindi andati a controllare, thread per thread il pthread_self(che ritorna l'ID del thread) ed ognugno era diverso. Questo significa che ogni thread creato era diverso da quello precedente.
A questo punto com'e' possibile che il secondo, terzo, quarto, ecc ecc... e successivi threads vadano ad intereagire con quella variabile OGNI VOLTA LOCALMENTE DICHIARATA?
Facendo altre prove abbiamo creato un altro thread(chiamamolo Y) che non fa nulla alla variabile x e nel quale non viene nemmeno dichiarata, ed abbiamo testato il programma in questa maniera:
Codice:
1) thread_x ---- "1"
2) thread_x ---- "2"
3) thread_x ---- "3"
4) thread_Y ---- "ciao sono Y e non ho niente a che fare con la variabile x"
5) thread_x ---- "-8245891"
6) thread_x ---- "-8245890"
Tutto cio' come diavolo e' possibile? Sinceramente non sappiamo piu' cosa pensare e a questo punto crediamo che ci sfugga davvero qualcosa di grosso sui threads. Anche perche' la definizione dell'uso delle variabili nei threads dice che:
Quote:
Originariamente inviato da definizione
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.

__________________
spammo un casino!
Gnappy è offline   Rispondi citando il messaggio o parte di esso
Old 06-11-2007, 15:38   #3
cionci
Senior Member
 
L'Avatar di cionci
 
Iscritto dal: Apr 2000
Città: Vicino a Montecatini(Pistoia) Moto:Kawasaki Ninja ZX-9R Scudetti: 29
Messaggi: 53971
Si può vedere il codice ?
cionci è offline   Rispondi citando il messaggio o parte di esso
Old 06-11-2007, 16:17   #4
dnarod
Senior Member
 
L'Avatar di dnarod
 
Iscritto dal: Nov 2002
Messaggi: 4329
è enorme, si fa solo confusione...metto le parti significative...

-------------------------
dal main:
Codice:
[...]
pthread_t T;
[...]
while(1) {
  pthread_create(&T, NULL, ilnostrothread, NULL);
}
[...]
dal codice del thread:
Codice:
void* ilnostrothread() {
  [...]
  int x;
  x++;
  printf("%d\n", x);
  [...]
  pthread_exit(NULL);
}
-----------------------------

se viene fatta la stessa richiesta al server piu volte (si creano piu thread) la prima stampa 1, la seconda 2, ecc...le prove sono fatte a mano, quindi i thread muoiono sicuramente e non si incrociano mai...poi magari la cosa ha anche un suo senso logico, ma quel che interessa a me è altro, solo che non so come ottenerlo e non trovo informazioni da altre parti; spero di aver reso l idea, altrimenti mi sa pvt...
__________________
|18k+|slk800|a7n8x|1Gb/ddr400|Gf4mx440|Pio108|WD 160Gb|Case|Uni|Album|AnimeClick|OneManga|
|ClassicThrash!|BNR Metal|TrueMetal|Dime|Chuck|

Ultima modifica di dnarod : 06-11-2007 alle 16:33.
dnarod è offline   Rispondi citando il messaggio o parte di esso
Old 06-11-2007, 16:30   #5
cionci
Senior Member
 
L'Avatar di cionci
 
Iscritto dal: Apr 2000
Città: Vicino a Montecatini(Pistoia) Moto:Kawasaki Ninja ZX-9R Scudetti: 29
Messaggi: 53971
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.
Quindi se x cambia il suo stato senza che venga acceduta dal thread che la crea è possibile che si tratti di un buffer overflow...in pratica gli altri thread cercando di operare su PROPRI dati vanno erroneamente a sovrascrivere il contenuto di x
cionci è offline   Rispondi citando il messaggio o parte di esso
Old 06-11-2007, 16:38   #6
Gnappy
Member
 
Iscritto dal: Feb 2001
Città: Nelle Langhe, dove non c'è tecnologia ma solo buon vino
Messaggi: 154
Si, l'avevamo pensato anche noi però a questo punto come si può risolvere?

Cioè, che senso ha fare threads se poi le variabili PRIVATE di un thread vengono sovrascritte "per sbaglio" da un altro thread che sta scrivendo le sue private?
Non è che questo "per sbaglio" è dovuto a come chiamiamo/usiamo i threads? Non esiste una dichiarazione privata(ahhh Java come ti amo) per queste variabili?

Grazie in anticipo per l'attenzione e le risposte
__________________
spammo un casino!
Gnappy è offline   Rispondi citando il messaggio o parte di esso
Old 06-11-2007, 16:43   #7
cionci
Senior Member
 
L'Avatar di cionci
 
Iscritto dal: Apr 2000
Città: Vicino a Montecatini(Pistoia) Moto:Kawasaki Ninja ZX-9R Scudetti: 29
Messaggi: 53971
Il modo per risolvere è trovare a cosa è dovuto il buffer overflow
Non certo rendere più "privata" la variabile...

Il valore in cui viene modificato è sempre lo stesso ?
cionci è offline   Rispondi citando il messaggio o parte di esso
Old 06-11-2007, 16:45   #8
dnarod
Senior Member
 
L'Avatar di dnarod
 
Iscritto dal: Nov 2002
Messaggi: 4329
il fatto è che qui funziona cosi:
1)creo il thread
2)il trhead fa quello che deve fare e di sicuro muore (perche lo creiamo a mano con un menu maffo controllato da shell)
3)solo dopo creiamo il prossimo (con un buon secondo di ritardo almeno)...

han tempo a morire 100 threads in quell arco di tempo (alla fine all interno del codice fara si e no una decina di operazioni, cioe nulla), cioe dovrebbe essere impossibile che un thread possa sporcare un altro, anche se è l unica idea che è venuta in mente anche a me...
__________________
|18k+|slk800|a7n8x|1Gb/ddr400|Gf4mx440|Pio108|WD 160Gb|Case|Uni|Album|AnimeClick|OneManga|
|ClassicThrash!|BNR Metal|TrueMetal|Dime|Chuck|
dnarod è offline   Rispondi citando il messaggio o parte di esso
Old 06-11-2007, 16:55   #9
cionci
Senior Member
 
L'Avatar di cionci
 
Iscritto dal: Apr 2000
Città: Vicino a Montecatini(Pistoia) Moto:Kawasaki Ninja ZX-9R Scudetti: 29
Messaggi: 53971
Mi viene un dubbio...ma questa x la inizializzi ogni volta ? Come fai ad assegnare il valore iniziale a x ?
cionci è offline   Rispondi citando il messaggio o parte di esso
Old 06-11-2007, 17:06   #10
Gnappy
Member
 
Iscritto dal: Feb 2001
Città: Nelle Langhe, dove non c'è tecnologia ma solo buon vino
Messaggi: 154
Viene inizializaata ad ogni chiamata di quel thread. Non viene settato un valore iniziale, int x; lo inizializza a 0.
Questo la prima volta, poi dalla seconda in poi prende l'ultimo valore di x...
__________________
spammo un casino!
Gnappy è offline   Rispondi citando il messaggio o parte di esso
Old 06-11-2007, 17:11   #11
cionci
Senior Member
 
L'Avatar di cionci
 
Iscritto dal: Apr 2000
Città: Vicino a Montecatini(Pistoia) Moto:Kawasaki Ninja ZX-9R Scudetti: 29
Messaggi: 53971
int x;

non inizializza assolutamente a zero, se lo fa è dipende dal compilatore...
La variabile deve essere inizializzata a zero
cionci è offline   Rispondi citando il messaggio o parte di esso
Old 06-11-2007, 17:28   #12
Gnappy
Member
 
Iscritto dal: Feb 2001
Città: Nelle Langhe, dove non c'è tecnologia ma solo buon vino
Messaggi: 154
Si, diciamo che mi sono spiegato male, lo so che viene inizializzata random nel range dell'int, però in questo caso abbiamo fatto una comunissima prova ed al primo passaggio i++ printa "1", quindi si, dipende dal compilatore ma questo poco ci interessa.
Se, ad esempio, la inizializzassimo OGNI volta a 0, esempio:
Codice:
void* ilnostrothread() {
  [...]
  int x = 0;
  x++;
  printf("%d\n", x);
  [...]
  pthread_exit(NULL);
}
Ad ogni chiamata di questo thread avremo sempre printato "1". Quindi, senza ragionarci su, potremmo dire che per risolvere il problema iniziale basterebbe inizializzare a 0/NULL tutte le variabili di cui faremo uso all'interno del thread.
Questo si, andrebbe bene nel caso in cui lanciassimo solo un thread dello "stesso tipo"( pthread_create(&T, NULL, ilnostrothread, NULL); ) alla volta aspettando la sua terminazione con il pthread_join nel main oppure con un mutex che tenga lockato il thread in tutta la sua computazione. Così abbiamo già appurato che funziona, però viene a mancare tutta la parte concorrenziale del progetto.
Finalmente sono riuscito a spiegare il problema? Scusami ma spiegarlo è più difficile di quel che sembra..
__________________
spammo un casino!
Gnappy è offline   Rispondi citando il messaggio o parte di esso
Old 06-11-2007, 17:47   #13
cionci
Senior Member
 
L'Avatar di cionci
 
Iscritto dal: Apr 2000
Città: Vicino a Montecatini(Pistoia) Moto:Kawasaki Ninja ZX-9R Scudetti: 29
Messaggi: 53971
Come ho già detto la variabile x è allocata per ogni istanza del thread, quindi non puoi "sperare" che alla successiva istanza mantenga il valore dato precedentemente.


Per far sì che lo mantenga dovresti passare l'indirizzo di x alla pthread_create...

Ad esempio:
Codice:
int x; //allocata solo una volta


....
....

pthread_create(&T, NULL, ilnostrothread, &x);


void* ilnostrothread(void *arg)
{
   int *x = (int *)arg;

  (*x)++;

  printf(("%d\n", *x);
}
Nota che in questo modo funziona bene solo con un solo thread ilnostrothread in esecuzione...se ne volete avere più di uno contemporaneamente allora avrete problemi di concorrenza e quindi dovreste usare una mutex (ad esempio potete passare l'indirizzo di una struttura contenente x e l'istanza della mutex che lavora su x come argomento del thread).
cionci è offline   Rispondi citando il messaggio o parte di esso
Old 06-11-2007, 17:50   #14
Gnappy
Member
 
Iscritto dal: Feb 2001
Città: Nelle Langhe, dove non c'è tecnologia ma solo buon vino
Messaggi: 154
Si, e ti ringrazio molto della risposta e del tempo che dietro ci stai perdendo, grazie davvero.

Però noi non "speriamo" che la variabile sia condivisa, noi vogliamo che le variabili presenti nei vari threads non siano assolutamente condivise, questo perchè ognuno è assestante.

Abbiamo usato questo esempio della x, ma l'abbiamo usato solo per provare che questa "incredibile condivisione" esiste e ci sta mandato a quel paese tutta la logica del progetto...
__________________
spammo un casino!

Ultima modifica di Gnappy : 06-11-2007 alle 17:52.
Gnappy è offline   Rispondi citando il messaggio o parte di esso
Old 06-11-2007, 18:01   #15
cionci
Senior Member
 
L'Avatar di cionci
 
Iscritto dal: Apr 2000
Città: Vicino a Montecatini(Pistoia) Moto:Kawasaki Ninja ZX-9R Scudetti: 29
Messaggi: 53971
Ricapitolando...

Il thread viene fatto girare (chiamiamolo thread1), dichiarate una variabile locale ad un thread. e la variabile ha valore, casualmente devo aggiungere, zero...incrementate questa variabile e la stampate. Stampa 1. A questo punto il thread termina e lo spazio occupato dalla variabile x viene liberato.

Il thread viene fatto girare nuovamente (chiamiamolo thread2), dichiarate una variabile locale ad un thread. e la variabile ha valore pseudocasuale. Voi invece vorreste che avesse valore 1. E' giusto ?
Se c'è qualcosa di errato nel ragionamento che faccio cerca di riprendere le mie parole e di modificarle ad hoc.


Se è giusto allora avete sbagliato dal punto di vista logico in quanto l'istanza di x in thread1 non ha niente a che vedere con l'istanza di x in thread2. Sono variabili diverse con tempi di vita disgiunti. L'unico modo per avere 1 in x nella seconda istanza del thread è che abbiate la fortuna che x, quella nuova, vada ad occupare la stessa posizione di memoria della x vecchia e che nel frattempo nessuno abbia scritto in quella locazione di memoria.
cionci è offline   Rispondi citando il messaggio o parte di esso
Old 06-11-2007, 18:02   #16
tomminno
Senior Member
 
Iscritto dal: Oct 2005
Messaggi: 3306
Quote:
Originariamente inviato da Gnappy Guarda i messaggi
Si, e ti ringrazio molto della risposta e del tempo che dietro ci stai perdendo, grazie davvero.

Però noi non "speriamo" che la variabile sia condivisa, noi vogliamo che le variabili presenti nei vari threads non siano assolutamente condivise, questo perchè ognuno è assestante.

Abbiamo usato questo esempio della x, ma l'abbiamo usato solo per provare che questa "incredibile condivisione" esiste e ci sta mandato a quel paese tutta la logica del progetto...
Ma cosa ci dovete fare con questa x?
Volete contare quanti thread sono stati eseguiti? Se si deve essere comune a tutti i thread.
Altrimenti per il codice che avere postato x potrà assumere sempre e solo il valore 1.

Per quanto rigurarda l'inizializzazione, può essere che le successive istanze del thread vadano ad occupare le medesime celle di memoria del precedente, con la conseguenza che per caso la x riassume il valore che aveva in precedenza.
Quando viene istanziato un thread che non viene allocato nello stesso punto dei precedenti succede esattamente quello che riportate.

Quella variabile deve essere inizializzata da ogni istanza del thread, ciò significa che, siccome non la volete condividere tra thread, potrà valere sempre e solo 1 alla fine del thread.
tomminno è offline   Rispondi citando il messaggio o parte di esso
Old 06-11-2007, 18:13   #17
Gnappy
Member
 
Iscritto dal: Feb 2001
Città: Nelle Langhe, dove non c'è tecnologia ma solo buon vino
Messaggi: 154
Quote:
Originariamente inviato da cionci Guarda i messaggi
Se c'è qualcosa di errato nel ragionamento che faccio cerca di riprendere le mie parole e di modificarle ad hoc.
Quote:
Originariamente inviato da cionci_edited
Il thread viene fatto girare (chiamiamolo thread1), dichiarate una variabile locale ad un thread. e la variabile ha valore, casualmente devo aggiungere, zero...incrementate questa variabile e la stampate. Stampa 1. A questo punto il thread termina e lo spazio occupato dalla variabile x viene liberato.

Il thread viene fatto girare nuovamente (chiamiamolo thread2), dichiarate una variabile locale ad un thread. e la variabile ha valore pseudocasuale. Noi vorremmo che x avesse questo MALEDETTO valore pseudocasuale ed invece ha il MALEDETTO "1"(assegnato dal thread precedente, "thread1") dentro! Thread2 a questo punto farà "x++" e stamperà "2".
Il successivo "thread3" avrà "2", farà "x++" e stamperà "3".
Questo è assolutamente inamissibile! Le variabili sono dichiarate localmente e non devono risultare condivise in questa maniera

Guarda, oltretutto io e dnarod non credo che siamo 2 completi dementi della programmazione, non ci sono "bugs di storta" nel codice, tipo una globale int x dichiarata o porcate simili...

Credo di aver spiegato bene il problema qui e, se sei ancora così gentile da voler continuare ad aiutarci in questo problema, ti invito a rileggerlo. TY
__________________
spammo un casino!
Gnappy è offline   Rispondi citando il messaggio o parte di esso
Old 06-11-2007, 18:24   #18
tomminno
Senior Member
 
Iscritto dal: Oct 2005
Messaggi: 3306
I vostri problemi risiedono nel fatto che non inizializzate le variabili, probabilmente perchè siete abituati al Java che lo fa da sè, mentre il C non lo fa.

Come più volte ripetuto se non inizializzate le variabili il loro valore è random, e se per caso il vostro thread è allocato nelle stesse celle del precedente (cosa non certo rara, osservando in debug spesso si vedono le variabili riassumere il loro vecchio valore, magari anche della precedente istanza), allora per puro caso il valore assunto coincide con quello vecchio e quindi vedete come se la variabile fosse condivisa, in realtà è un vostro errore di programmazione decisamente elementare.
tomminno è offline   Rispondi citando il messaggio o parte di esso
Old 06-11-2007, 18:38   #19
Gnappy
Member
 
Iscritto dal: Feb 2001
Città: Nelle Langhe, dove non c'è tecnologia ma solo buon vino
Messaggi: 154
Quote:
Originariamente inviato da tomminno Guarda i messaggi
Ma cosa ci dovete fare con questa x?
Volete contare quanti thread sono stati eseguiti? Se si deve essere comune a tutti i thread.
No, non ci interessa. Questo int x lo usiamo per dimostrare che esiste una condivisione di variabili tra un thread e l'altro.

Quote:
Originariamente inviato da tomminno Guarda i messaggi
Altrimenti per il codice che avere postato x potrà assumere sempre e solo il valore 1.
E' proprio qui la cosa bella, NOI VORREMMO CHE FOSSE COSI', ma nella realtà dei fatti NON E' COSI'

Quote:
Originariamente inviato da tomminno Guarda i messaggi
Per quanto rigurarda l'inizializzazione, può essere che le successive istanze del thread vadano ad occupare le medesime celle di memoria del precedente, con la conseguenza che per caso la x riassume il valore che aveva in precedenza.
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..

Quote:
Originariamente inviato da tomminno Guarda i messaggi
Quando viene istanziato un thread che non viene allocato nello stesso punto dei precedenti succede esattamente quello che riportate.
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.

Quote:
Originariamente inviato da tomminno Guarda i messaggi
Quella variabile deve essere inizializzata da ogni istanza del thread, ciò significa che, siccome non la volete condividere tra thread, potrà valere sempre e solo 1 alla fine del thread.
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:
Codice:
void* ilnostrothread() {
  [...]
  int x = 0;
  sleep(2);
  x++;
  printf("%d\n", x);
  [...]
  pthread_exit(NULL);
}
Quote:
Originariamente inviato da Esempio con 3 threads che arrivano in maniera NON concorrenziale(sequenzialmente) a 5 secondi uno dall'altro
SIMULAZIONE:
1) creazione ilnostrothread_1, inizio computazione ilnostrothread_1, int x = 0, sleep, context switch, proseguimento computazione ilnostrothread_1, x++, x = 1, "1", pthread_exit.
2) creazione ilnostrothread_2, inizio computazione ilnostrothread_2, int x = 0, sleep, context switch, proseguimento computazione ilnostrothread_2, x++, x = 1, "1", pthread_exit.
3) creazione ilnostrothread_3, inizio computazione ilnostrothread_3, int x = 0, sleep, context switch, proseguimento computazione ilnostrothread_3, x++, x = 1, "1", pthread_exit.

FUNZIONA!
Quote:
Originariamente inviato da Esempio con 3 threads che arrivano in maniera concorrenziale(conteporeaneamente)
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.

NON FUNZIONA!
Grazie anche a te per l'aiuto e la voglia di darci una mano
__________________
spammo un casino!
Gnappy è offline   Rispondi citando il messaggio o parte di esso
Old 06-11-2007, 18:46   #20
Gnappy
Member
 
Iscritto dal: Feb 2001
Città: Nelle Langhe, dove non c'è tecnologia ma solo buon vino
Messaggi: 154
Quote:
Originariamente inviato da tomminno Guarda i messaggi
I vostri problemi risiedono nel fatto che non inizializzate le variabili, probabilmente perchè siete abituati al Java che lo fa da sè, mentre il C non lo fa.

Come più volte ripetuto se non inizializzate le variabili il loro valore è random, e se per caso il vostro thread è allocato nelle stesse celle del precedente (cosa non certo rara, osservando in debug spesso si vedono le variabili riassumere il loro vecchio valore, magari anche della precedente istanza), allora per puro caso il valore assunto coincide con quello vecchio e quindi vedete come se la variabile fosse condivisa, in realtà è un vostro errore di programmazione decisamente elementare.
Guarda, si hai assolutamente ragione, ma ribadisco che l'esempio con la x è solo un BANALISSIMO esempio dove non l'abbiamo inizializzata per dimostrare l'incremento tra un thread e l'altro. Il fatto che su Unix Solaris 10 il gcc la voglia inizializzare di suo a 0 è un altro paio di mani che non mi interessa approfondire...
Nel nostro programma ogni variabile è inizializzata LOCALMENTE. Quindi siamo nell'esempio "Esempio con 3 threads che arrivano in maniera concorrenziale(conteporeaneamente)" del mio reply appena postato. Come vedi qui la x che sia inizializzata o meno conta poco, qua va a quel paese l'intera concorrenzialità del programma. E il motivo è dell'inspiegabile situazione in cui queste maledette variabili decidono di meschiarsi tra i threads.

Entrambi(io e dnarod) abbiamo ben chiaro cosa succede quando questo codice viene eseguito e quella simulazione è uno dei possibili casi(poi dipende dallo scheduler), ma non abbiamo la minima idea di come risolvere per il semplice fatto che IN TEORIA QUELLE VARIABILI NON SI DOVREBBERO CONDIVIDERE.

Grazie ancora per il supporto..
__________________
spammo un casino!
Gnappy è offline   Rispondi citando il messaggio o parte di esso
 Rispondi


Samsung Galaxy S25 Edge: il top di gamma ultrasottile e leggerissimo. La recensione Samsung Galaxy S25 Edge: il top di gamma ultraso...
HP Elitebook Ultra G1i 14 è il notebook compatto, potente e robusto HP Elitebook Ultra G1i 14 è il notebook c...
Microsoft Surface Pro 12 è il 2 in 1 più compatto e silenzioso Microsoft Surface Pro 12 è il 2 in 1 pi&u...
Recensione REDMAGIC Astra Gaming Tablet: che spettacolo di tablet! Recensione REDMAGIC Astra Gaming Tablet: che spe...
Dopo un mese, e 50 foto, cosa abbiamo capito della nuova Nintendo Switch 2 Dopo un mese, e 50 foto, cosa abbiamo capito del...
Amazon in delirio da sconti: 22 articoli...
EOLO ha più di 700 mila utenti in...
Una spin-off del MIT ha creato dei super...
Il radiatore di una BMW M4 per raffredda...
OpenAI accelera su GPT-5: lancio estivo ...
È indietro e deve reagire: il CEO...
Samsung Galaxy Buds3 a 86€, Bose QuietCo...
Addio feed MSN: Microsoft punta tutto su...
GPD Win 5 con il superchip AMD fa volare...
Top 7 Amazon bestseller: classifica scon...
Nexamp ha un'idea per attivare un campo ...
L'app PostePay non funzionerà pi&...
Svelati i colori di iPhone 17 Pro: tutte...
Elon Musk rompe il silenzio sulla Tesla ...
AirPods Pro 2 tornano a 199€ e restano l...
Chromium
GPU-Z
OCCT
LibreOffice Portable
Opera One Portable
Opera One 106
CCleaner Portable
CCleaner Standard
Cpu-Z
Driver NVIDIA GeForce 546.65 WHQL
SmartFTP
Trillian
Google Chrome Portable
Google Chrome 120
VirtualBox
Tutti gli articoli Tutte le news Tutti i download

Strumenti

Regole
Non Puoi aprire nuove discussioni
Non Puoi rispondere ai messaggi
Non Puoi allegare file
Non Puoi modificare i tuoi messaggi

Il codice vB è On
Le Faccine sono On
Il codice [IMG] è On
Il codice HTML è Off
Vai al Forum


Tutti gli orari sono GMT +1. Ora sono le: 11:52.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
Served by www3v