Discussion :

[ram-0000]

Bonjour,

Je travaille sur un soft multi thread et j'ai un problème sur une portion de code que je veux protéger par une section critique.

J'utilise pour cela un objet CRITICAL_SECTION. Pas de problème, je protège bien ma portion de code des autres threads par contre, je ne suis pas protégé si le thread qui a locké la section critique rappelle à nouveau la fonction. J'ai une réentrance du même thread.

Je cherche à détecter ce type de problème pour quitter le plus vite possible la fonction rappellée et éviter cette réentrance.

Avez vous déjà rencontré cette problématique et comment vous l'avez vous résolue.

[Médinoc]

Généralement, quand j'utilise une variable globale (ou thread-locale) et que j'ai une histoire de réentrance, je me retrouve à lui donner une sémantique de pile.

Sinon, une façon d'éviter la réentrance dans une section critique est tout bonnement de s'assurer que dans cette section critique, on n'appelle aucune fonction susceptible de provoquer une réentrance...

Normalement, ces points doivent être faciles à identifier (typiquement MessageBox(), SendMessage(), SendMessageTimeout() sans le flag SMTO_BLOCK, les appels d'objet COM dans un autre thread, etc.)

[ram-0000]

Le problème est que la fonction que je souhaite protéger (appelons la TRACE) est dans une DLL. Cette fonction TRACE() va appeler une fonction définie par l'utilisateur (par callback ou par PostMessage() ou SendMessage()).

Si dans le traitement de la fonction de rappel ou dans le traitement du message, le développeur appelle la fonction TRACE(), j'ai une réentrance

Le code de la DLL dans lequel se trouve la fonction TRACE() et le code du programme utilisateur ne sont pas dans le même projet et donc pas forcémment écrit par le même utilisateur. Je n'ai donc pas la possibilité de m'assurer que l'utilisateur ne va pas provoquer une réentrance sans le savoir.

[Médinoc]

Dans ce cas, tu as un autre problème en plus: Si la trace appelle une callback utilisateur qui elle-même appelle la trace, tu risques une récursivité infinie ---> Boum la pile!

Je pense qu'il faut interdire, dans la spec, tout appel à TRACE dans la callback, pour cette raison.

Ou bien, dans la définition même de TRACE(), ignorer tout appel récursif et retourner immédiatement.

[ram-0000]

Dans ce cas, tu as un autre problème en plus: Si la trace appelle une callback utilisateur qui elle-même appelle la trace, tu risques une récursivité infinie ---> Boum la pile!

C'est exactement le problème

Je pense qu'il faut interdire, dans la spec, tout appel à TRACE dans la callback, pour cette raison.

Je peux effectivement l'écrire mais cela n'empêche par l'utilisateur de la faire. Les doc ne sont jamais lues et parfois si le code est complexe et implique des classes qui impliquent ..., on peut perdre de vue ou oublier que l'on est dans une callback et que cet appel est interdit.

Ou bien, dans la définition même de TRACE(), ignorer tout appel récursif et retourner immédiatement.

C'est ce vers quoi je suis parti, un booleen statique dans la fonction TRACE qui détecte s'il est déjà positionné et qui sort immédiatement si il y a détection de réentrance. Mais je cherchais s'il y avait un moyen plus intelligent.

[Médinoc]

C'est ce vers quoi je suis parti, un booleen statique dans la fonction TRACE qui détecte s'il est déjà positionné et qui sort immédiatement si il y a détection de réentrance. Mais je cherchais s'il y avait un moyen plus intelligent.

Je ne pense pas. Surtout si la trace est déjà protégée par une section critique.

[ram-0000]

Je ne pense pas. Surtout si la trace est déjà protégée par une section critique.

OK alors, merci