oliparcol a écrit :
il faut aussi savoir qu'il n'y a qu'un thread qui écrit dans le tableau, les autres ne font que le lire
|
C'est pas une raison. Les accès concurrentiels n'ont rien à voir avec ce problème.
Citation :
Et de plus le tableau est déclaré dans le main.
|
C'est pas une raison non plus: utiliser des adresses de stack comme moyen d'échange pour des données, c'est la porte ouverte à toute sorte de conneries. A moins de savoir, encore une fois, ce que tu fais.
Citation :
ok mais dans ce cas, quelle serait la solution la plus intelligente ?
|
- Le déclarer static (ou comme variable globale) pour qu'il soit dans la zone data.
- L'allouer avec un malloc() pour qu'il soit dans le tas.
Les allocations sur la pile, ca ne sert qu'a une chose: avoir des variables auto pour lesquelles on a pas à s'embêter la tête avec le stockage, mais il est _temporaire_ : quand tu vas créer ton thread, le thread créé doit recopier les données, et non pas garder un pointeur dessus.
La solution typique: le thread créateur, juste après le pthread_create(3), attend sur une condvar qui sera mise à 1 quand le thread créé aura fini de copier les valeurs. Cette condvar peut être évidemment sur la pile, vu que celle-ci n'aura pas encore été nettoyée par le retour de fonction.
Amha, si tu veux faire des pthreads proprement, je te recommande chaudement de lire le bouquin de Butenhof.
Message édité par Gf4x3443 le 15-12-2008 à 13:19:21
---------------
Petit guide Kerberos pour l'administrateur pressé