Pb de pointeur mal détruit

Bonjour,
j'utilise dans un prog une liste chainée où chacun des maillons est alloué avec new, desalloué avec delete.
Mon probleme : si dans le thread n°1 je travaille sur un maillon, et que dans le thread n°2 je détruits ce maillon (en le mettant à NULL apres le delete), je me retrouve dans le thread n°1 avec un maillon non nul, mais détruit, et du coup je ne peux pas faire if(p != NULL)

En gros :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

thread 1 : csPile.Lock(); info = p->info; csPile.Unlock();   thread 2 : csPile.Lock(); delete p; p = NULL; csPile.Unlock();   thread 1 : csPile.Lock(); if(p != NULL) //ça passe info = p->info; //ça plante csPile.Lock();     Merci par avance

---

salut a tout reorganiser tu peux utiliser ça :

Code:

---

1 2 3 4

// example for AfxIsMemoryBlock CAge* pcage = new CAge( 21 ); // CAge is derived from CObject. ASSERT( AfxIsMemoryBlock( pcage, sizeof( CAge ) ) )

---

AfxIsMemoryBlock te diras si l'adresse allouer est valide.
:D

slt,
t'aurais pas un problème de synchronisation ?
normalement, si tu fais un Lock() ta structure de données doit être protégée, et tu dois être sûr que tant qu'elle est lockée, personne n'y a accès, donc si tu fais un delete et p=NULL, normalement, un thread qui veut y avoir accès doit être en attente de la libération de la ressource...
Si ton mécanisme de synchronisation est bien fait, le problème ne devrait pas se poser.

la liste chainee est bien protégée.
C'est simplement que dans le thread 1, je fais le unlock() pour laisser la main a un autre thread, et puis je la re-lock() pour faire du traitement dessus.
Et c'est dans ce laps de temps (entre le Unlock() et le lock()) où le 2nd thread intervient sur la liste chainée (et il en a le droit puisqu'elle n'est pas lockée), et qu'il delete le maillon. C'est ensuite que dans le thread 1 (apres le lock) ce maillon n'est pas nul, mais quand même détruit.

Alors qu'il soit détruit, c'est normal !! Mais qu'il ne soit pas nul (alors que je le met à NULL dans le thread 2), ça je comprends pas !!

comme c'est pas coherent soit ton lock echoue soit c''est pas la meme variable.

:D

AfxIsMemoryBlock plante ("user breakpoint caller from code ...") !!!

je t'assure qu'il n'y a pas de pb de lock() / Unlock().
Quand à la variable c'est la même, puisqu'en travaillant au debugger, je vois trés bien que l'adresse du maillon p est bien la même dans le thread 1 et dans le thread 2.

Je ne comprends donc pas

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

thread 1 : csPile.Lock(); info = p->info; //OK csPile.Unlock();   Sleep(10000); //C'est pendant ce temps que le thread2 accede à la liste   csPile.Lock(); if(p != NULL) //ça passe (ça ne devrait pas !!!!!) info = p->info; //ça plante csPile.Unlock();     thread 2 : csPile.Lock(); delete p; p = NULL; csPile.Unlock();

---

Hum,
csPile est donc un objet CCritcalSection. (OK ?)
Quelle est sa portée ? C'est bien une variable globale ?

oui

C'est pas pasque tu détruit un object et que tu mets son pointeur à NULL que tout les pointeurs le référençant vont être à NULL !

Citation:

---

Envoyé par bilb0t

C'est pas pasque tu détruit un object et que tu mets son pointeur à NULL que tout les pointeurs le référençant vont être à NULL !

---

Ben si normalement. Ou alors je t'ai mal compris

c'est incompréhensible ton pb il faudrait voir le code en entier
c'est pas possible ça doit etre gros comme une maison!
entre autre l'endroit ou sont declarées les variables etc...
:D

Alors pour solutionner mon probleme, je suis passé par un pointeur de pointeur.
Je crois que ça rejoint ce que disait bilbOt.

J'ai fait (sachant que *pp du thread1 <-> p du thread 2)

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

thread 1 : pile** pp = NULL; csPile.Lock(); info = (*pp)->info; //OK csPile.Unlock();   Sleep(10000); //C'est pendant ce temps que le thread2 accede à la liste   csPile.Lock(); if(*pp != NULL) //et là c'est bon info = (*pp)->info; csPile.Unlock();     thread 2 : csPile.Lock(); delete p; p = NULL; csPile.Unlock();

---

Vous voyez une incorrection ou qqch d'incohérent ?

Bonjour,
pourquoi utiliser Sleep ??? Il ne faut pas utiliser Sleep , j'ai fait la même remarque sur le forum C++ Builder .
Comme l'a suggéré mes prédecesseurs , c'est ( on s'en doute ) , un problème de synchronisation.
Mais par pitié ne pas utiliser Sleep c'est ça qui occasionne des blocages.
Pourquoi il faut absolument éviter Sleep : pour la bonne et unique raison que tu espères attendre mettons 10 sec soient 10000ms.
Le problème est : quel est le temps d'exécution des processus indépendants qui sont crées ? Y-a-t-il une bonne synchronisation ?
Et comment va tourner ton programme dans 3 ans sur une machine 2 fois plus rapide ?

A chaud comme cela difficile d'apporter une solution ,il faut peut-être utiliser des Event ou autres .

MSDN:

Citation:

---

You have to be careful when using Sleep and code that directly or indirectly creates windows. If a thread creates any windows, it must process messages. Message broadcasts are sent to all windows in the system. If you have a thread that uses Sleep with infinite delay, the system will deadlock. Two examples of code that indirectly creates windows are DDE and COM CoInitialize. Therefore, if you have a thread that creates windows, use MsgWaitForMultipleObjects or MsgWaitForMultipleObjectsEx, rather than Sleep.

---

Il n'y a pas de blocage !!
c'est simplement que si mon pointeur est détruit et remis à NULL dans le thread 2, il n'est pas NULL dans le thread 1.
A force d'essayer des trucs, j'en suis venu à l'utilisation d'un pointeur de pointeur passé au thread 1, et seul un pointeur de pointeur dans le thread 1 voit la mise à NULL dans le thread 2.

Mais je vous assure qu'il n'y a aucun probleme de blocage et de synchronisation.
Concernant le Sleep utilisé, il est vrai que ce n'est pas trés Catholique, mais c'est plus pour l'exemple que pour autre chose. En fait c'est pendant ces 10 secondes (j'aurais pu mettre 60 secondes ou même plus), qu'à la main (par une touche de raccourci incluse dans mon programme) je lance le thread 2 qui accede à la pile, et supprime un maillon !!

Alors, voyez-vous une autre manière de tester ce pointeur deleté et mis à NULL ?

Ok d'accord il n'ya pas de blocage mais qu'en est-il sur une autre machine dans un contexte d'exécution différent ?
Il faut trouver une autre méthode

En gros voici quel était mon probleme :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

char* p = new char[32]; //p vaut 0x00421ae0 strcpy(p, "le pointreur"); //*p = "le pointeur"   char* p2 = p; //p2 vaut 0x00421ae0, *p2 = "le pointeur"   delete p; //liberation de la memoire prise par p //avec *p = *p2 = "YYYYYYYYYYYYYYYY" p = NULL; //p vaut 0x00000000   //MAIS p2 vaut toujours 0x00421ae0

---

La seule maniere de voir au travers de p2 que p vaut NULL est de faire

Code:

---

1 2 3 4 5 6 7 8 9

char* p = new char[32]; //p vaut 0x00421ae0 strcpy(p, "le pointreur"); //*p = "le pointeur"   char** p2 = &p; //*p2 = p = 0x00421ae0, **p2 = "le pointeur"   delete p; //liberation de la memoire prise par p //avec *p = **p2 = "YYYYYYYYYYYYYYYY" p = NULL; //p = *p2 = 0x00000000

---

Donc je me suis bien fait avoir en pensant que lorsque l'on détruit un pointeur et qu'on le met à NULL, on va aussi mettre à NULL tous les pointeurs le référençant (ce qui soulignait bilbOt, donc attention abelman !)

Ok Je vais tester cela

Moi ça me semble tout a fait normal c'est le piége typique que l'on retrouve
dans une classe avec des données membres de type pointeur quand on a pas fait un constructeur de copie et d'affectation lorsque l'un des 2 mécanismes est évoqué on a 2 objets avec des pointeurs qui adressent la même mémoire
Lorsque l'un des 2 objets se détruit et fait son ménage l'autre objet a des pointeurs qui adressent du vent
C’est bien pour ça qu'au début je t'ai demande si on parlait de la même variable p dans 2 thread apparemment non.
Et pas un autre variable nommée p .
:D