Tester la validité d'un pointeur

Re-Bonjour,

J'ai un pointeur sur un objet de la classe CMyCall dont j'aimerais tester la validité au cours de l'exécution du programme.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

void f1(CMyCall* pCall) { f2(pCall); }   void f2(CMyCall* pCall) { ... //Lance un thread avec pCall en paramètre AfxBeginThread( (AFX_THREADPROC) _ThreadProc, (LPVOID) pCall );   }

---

Or dans ce thread, j'aimerais tester pCall avant de faire des actions dessus (answer, speak, drop)

Code:

---

1 2 3 4 5 6 7 8

UINT thread(LPVOID par) { CMyCall* pCall = (CMyCall*)par;   if(pCall) pCall->Answer(); if(pCall) pCall->Speak(); if(pCall) pCall->Drop(); }

---

Donc tout le problème est que pCall peut être détruit ailleurs en cours de programme, et ensuite mis à NULL, lorsque l'appel a été raccroché par l'autre partie par exemple.
La fonction qui se charge de ça, fait :

Code:

---

1 2	pCall->Deallocate(); pCall = NULL;

---

Quelle est la solution pour avoir accès au test if(pCall) dans mon thread, car là tel que j'ai fait le pointeur passé n'est pas averti de la mise à NULL ?

@+

Une solution, c'est d'utiliser les smart_pointer de boost

Enfin, je crois que c'est fait pour ça

Euh, ben sinon, au lieu de detruire ton objet par un delete, tu peut le detruire par un appel à

Code:

---

1 2 3 4 5 6

void deleteMyCall(CMyCall &(*pCall)) { delete (&pCall); pCall = NULL; }

---

Que tu definirais comme une fonction "globale"

Je suis pas sûr du tout de la syntaxe, mais l'idée c'est de passer par référence un pointeur à la fonction. Celle-ci detruit l'objet pointé et met à NULL la variable référencée.

Citation:

---

CMyCall &(*pCall))

---

Tu voulais dire CMyCall*& pCall ?

salut,
merci pour ton idée, je ne vois pas en quoi cela change quoique ce soit, puisque'au final tu ne fais que pCall = NULL ...
Je l'ai essayé et, à moins d'avoir mal fait, cela ne change rien.

En effet si l'appel en cours est perdu, et donc que je désalloue l'appel et le met à NULL, je vois bien dans mon thread que mon pCall reste non NULL, mais pointe vers une zone mémoire libérée.

Je sais bien que ceci est normal car en fin de compte je ne peux pas demander à tous les pointeurs référençant un objet de dévenir NULL lorsque je détruits cet objet et que je mets son pointeurs à NULL.

Mais je cherche une solution ...

Il te faut passer par un objet supplémentaire spécialisé dans la gestion de la vie de ton CMyCall. On t'a conseillé les pointeurs intelligents de boost, c'est un bon conseil.
http://c.developpez.com/faq/cpp/?pag...OST_shared_ptr
Combiné a un weak_ptr, tu peux obtenir l'effet recherché (tester la validité d'un pointeur), avec plus de sécurité (empecher la destruction de l'objet pendant qu'il est utilisé, car rien dans ton exemple n'empeche deleteMyCall() de détruire ton objet alors que pCall->Answer() est en cours d'exécution)

En général, je jongle avec deux approches que je mélange parfois selon les accès:

- Dabord ceux qui surveillent le pointeur qui peut disparaitre sont des observateurs qui vont recevoir des notifications comme quoi le pointeur peut être invalidé.

- Ensuite, de plus en plus j'utilise des LockPtr plus ou moins évolués suivant les cas. Ils s'occupent d'encapsuler la donnée pouvant être détruite depuis n'importe quel thread. Ce qui me permet de ne pas altérer le pointeur (typiquement le détuire) tant qu'une opération est en cours dessus. Je m'inspire pour cela d'un article d'Andrei Alexandrescu relatif à une utilisation originale du mot clé mutable pour éliminer les courses -- l'article se retrouve depuis son site.

Si tu passe un pointeur de pointeur a ton thread, et que dans le programme tu fais pointeur = 0; le pointeur de pointeur pointera vers zero. C'est gagné.

Merci pour vos réponses,

Aurelien : je vais étudier les pointeurs de boost, que je ne connais pas du tout encore. De plus, quand tu dis "(empecher la destruction de l'objet pendant qu'il est utilisé, car rien dans ton exemple n'empeche deleteMyCall() de détruire ton objet alors que pCall->Answer() est en cours d'exécution)", tu as tout a fait raison

Luc : concernant ton premier point, existe-t-il un DP sur les observateurs ou des exemples de mise en oeuvre ?
Ensuite, je vais m'informer de traitement proposé à base de LockPtr, mais sachant que ce que je souhaite, en plus de pouvoir l'utiliser protégé par Lock, c'est savoir s'il a été détruit ou pas, et donc s'il est bien valide.

Niamorh : je ne peux pas faire ce que tu dis, car la fonction qui passe le pointeur au thread n'est pas celle qui le crée et qui le détruit. Il y a eu avant ça diverses affectations de pointeurs depuis la création de l'objet initial, et elle passe au thread un pointeur le référençant. Donc si je suis ton raisonnement, je passe un pointeur référençant un pointeur qui n'est pas celui que je mets à NULL ailleurs. Donc à mon avis, cela ne peut pas fonctionner.


Une autre solution pourrait consister, avant de vouloir s'en servir de repartir systématiquement à sa recherche pour savoir si on le retrouve encore dans les piles des couches + basses (donc s'il n'a pas encore été détruit), mais cela devient vite trés fastidieux.


PS : En tout cas, j'a bien l'impression que c'est pas si simple que ça ...

Qu'il y ait pointeur intelligent ou non, il sera indispensable de faire du verrouillage: Comme l'a dit Aurelien (accent?), sans verrouillage l'objet pourrait être désalloué avant entre le moment où le thread vérifie et celui où il l'utilise.

Au passage:

Citation:

---

Envoyé par olive_le_malin

Code:

---

AfxBeginThread( (AFX_THREADPROC) _ThreadProc, (LPVOID) pCall );

---

---

Le premier cast est très mauvais : Si ça ne compile pas sans la cast, c'est 80% de chances de plantage.
Tu dois supprimer ton cast et corriger la signature de _ThreadProc au besoin.

C'est certain, une synchronisation avant d'utiliser le pointeur est necessaire si tu fais un delete quelque part ou pour tout acces non thread safe.

Mais je maintiens que si tout tes threads possèdent un pointeur vers le pointeur principal, il n'y a plus de problèmes pour savoir quand ton pointeur n'est plus valide. Suffit de ne passer a chaque fois que du Objet** entre les interlocuteurs. C'est pas très contraignant à recoder.

Danc ce genre de cas, je serais plutôt pour centraliser le pointeur lui-même dans une structure et passer partour un pointeur vers la structure en question: Cela permet d'éviter de se balader avec des ** partout.

Ou encore, passer un objet qui renferme le pointeur de pointeur ou le pointeur de la structure contenant le pointeur. Les Smart Pointers de boost appartiennent à la catagorie "objet qui renferme le pointeur de la structure contenant le pointeur"...

Ca à l'air pas mal alors.

Il faudra que je me renseigne la dessus. J'ai toujours tendance à vouloir n'utiliser que le minimum de libs souvent au détriment de la complexité de mon code.

Citation:

---

Envoyé par NiamorH

Mais je maintiens que si tout tes threads possèdent un pointeur vers le pointeur principal, il n'y a plus de problèmes pour savoir quand ton pointeur n'est plus valide.

---

La gestion de la concurrence est plus complexe qu'il n'y parrait.

Code:

---

if(pCall) pCall->Answer();

---

ton thread peut etre interrompu juste (ou peu) apres que le test ait réussit, et, pas de bol, l'autre thread peut détruire pCall a ce moment la. Résultat : Answer va etre exécuté sur un objet détruit...

A partir du moment ou une ressource est partagée, il faut un mécanisme commun de gestion de la vie de cette ressource, sinon n'importe qui peut détruire la ressource pendant qu'un autre l'utilise.

non c'est certain cela ne remplace pas des synchronisations, mais je sais qu'à l'interieur des sections critiques j'aime bien faire des test if(m_truc) et etre sur que si mon objet n'est pas 0 alors il est toujours valide plutot que de faire appel a autre chose pour le determiner.

Dans ce cas, il peut être intéressant de mettre la section critique dans la même structure que le pointeur...

Et c'est ce que fait boost...

Bon, ben je vois bien qu'il va falloir que je m'interesse de plus prés à boost ...
:D
ça sera l'occasion !

Les observateurs correspondent bien à un pattern... éponyme.


Quant à boost, je doute que cela soit suffisant. Il y a bien un lock, mais au niveau des références comptées. Nullement au niveau des opérations exécutées : il ne faudrait pas que l'objet soit détruit durant l'exécution d'une de ses opérations.

Sans parler que cela ne sera pas d'une grande utilité quand on manipule des tâches suicidaires (elles reçoivent le message "va mourrir" et puis se terminent seules dans leur coin (i.e. dans leur(s) thread(s) une fois prêtes).


Le test "if (p) p->operation();" résume bien des choses. Après avoir testé p, il ne faut surtout pas qu'il soit détruit avant le début de l'opération, ni même pendant.

Grossièrement, je définis des proxies qui à leur création lockent la ressource (si disponible), et ensuite forwardent (sans mourrir) l'opération à l'objet protégé. À leur destruction, le lock est libéré. La destruction de la ressource s'appuyant sur le même lock -- que le lock soit réentrant, R/W, ... peu importe.
Le proxy étant employé comme une variable locale sur la pile ne pouvant mourrir que de fin de portée.

Si on n'utilise que des pointeurs intelligents, comment l'objet peut-il etre détruit durant l'exécution d'une de ses opérations ?

Code:

---

1 2 3 4 5 6 7

weak_ptr<CMyCall> pCall;   if(shared_ptr<CMyCall> p = pCall.lock()) { p->Answer(); }

---

par contre, pour passer le weak_ptr en parametre au thread, c'est pas evident.

Pour ça, je pense qu'il faudra le "boxer" sur le tas, avec un pointeur stupide, pour le passer au thread.

Citation:

---

Envoyé par Aurelien.Regat-Barrel

Si on n'utilise que des pointeurs intelligents, comment l'objet peut-il etre détruit durant l'exécution d'une de ses opérations ?

---

Depuis un autre thread. Il suffit d'un delete this. Juste avant de le déclencher, il faut notifier tous les observateurs que la vue sur la ressource encapsulée n'est plus utilisable.

Mais j'avoue que tu me mets le doute. N'ayant pas eu accès à boost (question de génération de compilo), j'ai dû réinventer des roues spécialisées à mes problèmes.
Il n'est finalement peut-être pas impossible qu'uniquement avec des weak_ptr, et peut-être même un "enable shared from this" on s'en sorte, c'est à étudier.