Discussion :

[olive_le_malin]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 ?

@+

[buzzkaido]

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

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

[buzzkaido]

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

[loufoque]

CMyCall &(*pCall))

Tu voulais dire CMyCall*& pCall ?

[olive_le_malin]

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 ...

[Aurelien.Regat-Barrel]

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)

[Médinoc]

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:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

[NiamorH]

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.

[Médinoc]

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"...

[NiamorH]

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.

[Aurelien.Regat-Barrel]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

[NiamorH]

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.

[Médinoc]

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

[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 ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

[Médinoc]

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

[Luc Hermitte]

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.