Problème de multithreading

Le
Grég
Bonjour,

J'ai une application du type MTMDI (exemple MSN) qui se fige sur certain pc
sitôt que j'ai plus d'un thread. Ce problème survient même avec mtmdi.exe
fournit par Microsoft.

Ce problème dit-il quelque chose à quelqu'un. J'avoue être un peu perdu mais
je soupçonne un problème hardware ou bios

Merci d'avance.

Grég.
  • Partager ce contenu :
Vos réponses Page 1 / 2
Trier par : date / pertinence
Vincent Burel
Le #9791851
"Grég" news:43ddcf8f$
Bonjour,

J'ai une application du type MTMDI (exemple MSN) qui se fige sur certain


pc
sitôt que j'ai plus d'un thread. Ce problème survient même avec mtmdi.exe
fournit par Microsoft.

Ce problème dit-il quelque chose à quelqu'un. J'avoue être un peu perdu


mais
je soupçonne un problème hardware ou bios ...



c'est peu probable, car avant de lancer votre application le systeme lance
des dizaine de thread, et il n'y pas de raison que ce soit votre thread qui
fasse apparaitre un tel probleme (sauf évidemment si dans ce thread , vous
faites des choses ole ole).

le blocage mutithread est généralement due à un deadlock, c'est à dire une
attente mutuelle, jetez un oeil du côté de votre méthodologie de
synchronization. Vérifiez aussi que vous ne créez pas un thread de priorité
plus forte (que le thread primaire) qui ne respirerait pas.

voila qqc conseils généraux
VB
Grég
Le #9791841
"Vincent Burel" news: 43ddd3f7$0$19701$

"Grég" news:43ddcf8f$
Bonjour,

J'ai une application du type MTMDI (exemple MSN) qui se fige sur certain


pc
sitôt que j'ai plus d'un thread. Ce problème survient même avec mtmdi.exe
fournit par Microsoft.

Ce problème dit-il quelque chose à quelqu'un. J'avoue être un peu perdu


mais
je soupçonne un problème hardware ou bios ...



c'est peu probable, car avant de lancer votre application le systeme lance
des dizaine de thread, et il n'y pas de raison que ce soit votre thread
qui
fasse apparaitre un tel probleme (sauf évidemment si dans ce thread , vous
faites des choses ole ole).

le blocage mutithread est généralement due à un deadlock, c'est à dire une
attente mutuelle, jetez un oeil du côté de votre méthodologie de
synchronization. Vérifiez aussi que vous ne créez pas un thread de
priorité
plus forte (que le thread primaire) qui ne respirerait pas.

voila qqc conseils généraux
VB




Problème d'attente mutuelle ou pas, après avoir flashé le bios, le
programme fonctionne.
De plus comme je l'ai mentionné même l'exemple de la MSDN le problème
apparait.

De ce fait, je ne comprends pas bien...
Chevalley J.-C
Le #9791831
J'ai trouvé une autre "solution" pour que ça fonctionne: si l'on désactive
l'option "Hyperthreading" dans le bios, le programme fonctionne...

A ce sujet, y a-t-il une façon d'obliger l'execution d'un programme
multithread dans "une partie du processeur" lorsqu'il est en mode
hyperethreading? options de compilations? ou manière de créer les threads?

Merci , JC




"Grég" news:43de3e39$
"Vincent Burel"

de
news: 43ddd3f7$0$19701$
>
> "Grég" > news:43ddcf8f$
>> Bonjour,
>>
>> J'ai une application du type MTMDI (exemple MSN) qui se fige sur


certain
> pc
>> sitôt que j'ai plus d'un thread. Ce problème survient même avec


mtmdi.exe
>> fournit par Microsoft.
>>
>> Ce problème dit-il quelque chose à quelqu'un. J'avoue être un peu perdu
> mais
>> je soupçonne un problème hardware ou bios ...
>
> c'est peu probable, car avant de lancer votre application le systeme


lance
> des dizaine de thread, et il n'y pas de raison que ce soit votre thread
> qui
> fasse apparaitre un tel probleme (sauf évidemment si dans ce thread ,


vous
> faites des choses ole ole).
>
> le blocage mutithread est généralement due à un deadlock, c'est à dire


une
> attente mutuelle, jetez un oeil du côté de votre méthodologie de
> synchronization. Vérifiez aussi que vous ne créez pas un thread de
> priorité
> plus forte (que le thread primaire) qui ne respirerait pas.
>
> voila qqc conseils généraux
> VB
>

Problème d'attente mutuelle ou pas, après avoir flashé le bios, le
programme fonctionne.
De plus comme je l'ai mentionné même l'exemple de la MSDN le problème
apparait.

De ce fait, je ne comprends pas bien...




Vincent Burel
Le #9791821
"Chevalley J.-C" news:43de58da$
J'ai trouvé une autre "solution" pour que ça fonctionne: si l'on désactive
l'option "Hyperthreading" dans le bios, le programme fonctionne...



C'est typiquement le signe qu'il y a un problème de synchronization entre
deux thread. le HyperThreading ou les station Dual Proc ne pardonnent pas
les erreur de synchronisation multithread.

A ce sujet, y a-t-il une façon d'obliger l'execution d'un programme
multithread dans "une partie du processeur" lorsqu'il est en mode
hyperethreading? options de compilations? ou manière de créer les threads?



non, pas vraiment, c'est Windows qui distribue les Thread dans les
processeurs... mais si vous faites une application avec deux thread, vous
pouvez pratiquement etre certains qu'il seront distribué chacun sur un proc
(ou file d'exécution).

VB
Paul Bacelar
Le #9791811
"Vincent Burel" news:43de611c$0$21258$

"Chevalley J.-C" news:43de58da$
J'ai trouvé une autre "solution" pour que ça fonctionne: si l'on
désactive
l'option "Hyperthreading" dans le bios, le programme fonctionne...



C'est typiquement le signe qu'il y a un problème de synchronization entre
deux thread. le HyperThreading ou les station Dual Proc ne pardonnent pas
les erreur de synchronisation multithread.

A ce sujet, y a-t-il une façon d'obliger l'execution d'un programme
multithread dans "une partie du processeur" lorsqu'il est en mode
hyperethreading? options de compilations? ou manière de créer les
threads?



non, pas vraiment, c'est Windows qui distribue les Thread dans les
processeurs... mais si vous faites une application avec deux thread, vous
pouvez pratiquement etre certains qu'il seront distribué chacun sur un
proc
(ou file d'exécution).

VB





Bien que l'analyse du problème soit bonne, une grosse inexactitude c'est
glissée en fin post.

On peut diriger sur quel processeur un thread s'exécute, voir
"SetProcessAffinityMask"

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/setprocessaffinitymask.asp



A n'utiliser que pour des raisons de performances et surtout pas pour cacher
une erreur évidente de protection des données partagées entre threads comme
le montre ces symptômes plus que caractéristiques.


PS à l'auteur de TestSiQQcToucheAMaPile (Vincent Burel): au lieu d'asséner
tes vérités souvent inexactes, pense à regarder les recommandations C2 de
l'armée américaine que WondowsNT/2000/XP/2003 suivent à la lettre (houps, à
la certification). Un MVP C++ qui te veux du bien, comme à tous les
utilisateurs des technologies M$.


--
Paul Bacelar
Microsoft MVP VC++
Vincent Burel
Le #9791771
"Paul Bacelar" news:drm397$s6n$
"Vincent Burel" news:43de611c$0$21258$
>
> "Chevalley J.-C" > news:43de58da$
>> J'ai trouvé une autre "solution" pour que ça fonctionne: si l'on
>> désactive
>> l'option "Hyperthreading" dans le bios, le programme fonctionne...
>
> C'est typiquement le signe qu'il y a un problème de synchronization


entre
> deux thread. le HyperThreading ou les station Dual Proc ne pardonnent


pas
> les erreur de synchronisation multithread.
>
>> A ce sujet, y a-t-il une façon d'obliger l'execution d'un programme
>> multithread dans "une partie du processeur" lorsqu'il est en mode
>> hyperethreading? options de compilations? ou manière de créer les
>> threads?
>
> non, pas vraiment, c'est Windows qui distribue les Thread dans les
> processeurs... mais si vous faites une application avec deux thread,


vous
> pouvez pratiquement etre certains qu'il seront distribué chacun sur un
> proc
> (ou file d'exécution).
>
> VB
>
>

Bien que l'analyse du problème soit bonne, une grosse inexactitude c'est
glissée en fin post.

On peut diriger sur quel processeur un thread s'exécute, voir
"SetProcessAffinityMask"



D'abord c'est SetThreadAffinityMask qui nous intéresse, ensuite je disais
"pas vraiment" parce qu'une application ne peut pas controler la
distribution que le systeme fait des divers thread systeme dans les
processeurs avant sont lancement. On ne peut pas non plus donner une
affinité à un thread indirectement crée, par exemple quand on lance un flux
de données, bref, tout un tas de paramètre inconnus pour vous qui limitent
la pertinence de donner un AffinityMask à un thread.

PS à l'auteur de TestSiQQcToucheAMaPile (Vincent Burel): au lieu d'asséner
tes vérités souvent inexactes,



Déjà le fait que vous ne reconnaissiez pas vos lacune (vous ne savez pas
comment fonctionne la pile d'un thread user sous Windows) est d'une
incorrection sans nom... Mais le fait que vous en rajoutiez alors que j'ai
fait la preuve de mes dires, c'est un scandale ! :-)

VB
Arnaud Debaene
Le #9791761
Chevalley J.-C wrote:
J'ai trouvé une autre "solution" pour que ça fonctionne: si l'on
désactive l'option "Hyperthreading" dans le bios, le programme
fonctionne...



Le plus probable (99% de chances), c'est que tu as réellement un bug de
synchronisation dans ton code, mais que ce bug ne se révèle que lorsque tu
es en hyperthread, dual-core ou multi-processeur.

La vraie solution consiste à accrocher un debogeur lorsque ton programme se
fige, et à examiner les pile d'appels des différents threads de ton
application pour identifier la cause du deadlock. Ce n'est pas un exercice
aisé d'identifier un deadlock, mais c'est indispensable.

Pour mémoire, un deadlock, ca se résume *toujours* à avoir deux locks
(setion critique, mutex ou autre...) A et B; Un thread a locké A et cherche
à locker B alors qu'un autre thread a locké B et cherche à locker A. La
difficulté vient ensuite du fait que ce "pattern" est généralement noyé au
milieu de nombreuses couche de code (ie, appel de fonctions) sur les
différents threads impliqués.

Arnaud
MVP - VC
Chevalley J.-C
Le #9791701
Un GRAND merci à VV,PB et AD.
En effet, les deux threads ont des problèmes de synchronisations à cause de
variables globales. Ces variables globales sont je pense misent dans des
sections critiques (ou autres) par l'OS sur des machines Multiprocesseurs ou
Hyperthreadings. Il y a certainement un "deadlock" sur une (ou plus) de ces
variables globales. J'ai essayé de trouver la variable concernée en
annalysant la pile des threads mais ai rien trouvé... Ma solution temporaire
(et j'en suis pas fier!) est SetProcessAffinityMask(..). L'autre solution
est comme je l'ai dit de "flasher" le bios. Ils ont du faire qqch. qui
améliore la gestion de threads en Hyperthreading.

Jean-Claude
Vincent Burel
Le #9791681
Attention, entendons nous bien, on vous dit qu'il y a un deadlock dans votre
code, ce n'est donc pas la peine de spéculer sur ce que le systeme fait ou
ne fait pas .

Un deadlock dans votre code ca veut dire que par exemple
- un thread appelle une fonction qui rentre dans une SectionCritique et dans
cette section critique appelle une autre fonction qui elle aussi veut
exécuter du code dans cette section critique. mais c'est visible dans votre
code, ce n'est pas un mystère de windows.
- Si vous utilisez des event, c'est par exemple un Wait qui est effectué sur
un event qui ne subit jamais de SetEvent. Ca peut arriver quand on fait un
ResetEvent après avoir fixer les flag de sortie par exemple. Ca peut arriver
quand on se perd dans les appels de fonctions et qu'un même thread attend
sur un event qu'il est lui-même censé relaché...

mais encore une fois c'est dans votre code, c'est explicite, il suffit de
dérouler temporellement le scenario de votre algorithme pour trouver
l'erreur. Encore une fois, un deadlock est toujours du à une mauvaise
gestion de la synchro, donc à une mauvaise construction de l'algorithme de
synchronization.

C'est sur ce genre de chose que vous devez vous focaliser, et non pas sur le
BIOS ou je ne sais quelle autre subodoration farfelues

VB

"Chevalley J.-C" news:
Un GRAND merci à VV,PB et AD.
En effet, les deux threads ont des problèmes de synchronisations à cause


de
variables globales. Ces variables globales sont je pense misent dans des
sections critiques (ou autres) par l'OS sur des machines Multiprocesseurs


ou
Hyperthreadings. Il y a certainement un "deadlock" sur une (ou plus) de


ces
variables globales. J'ai essayé de trouver la variable concernée en
annalysant la pile des threads mais ai rien trouvé... Ma solution


temporaire
(et j'en suis pas fier!) est SetProcessAffinityMask(..). L'autre solution
est comme je l'ai dit de "flasher" le bios. Ils ont du faire qqch. qui
améliore la gestion de threads en Hyperthreading.

Jean-Claude





Arnaud Debaene
Le #9791651
Chevalley J.-C wrote:
Un GRAND merci à VV,PB et AD.
En effet, les deux threads ont des problèmes de synchronisations à
cause de variables globales. Ces variables globales sont je pense
misent dans des sections critiques (ou autres) par l'OS sur des
machines Multiprocesseurs ou Hyperthreadings. Il y a certainement un
"deadlock" sur une (ou plus) de ces variables globales.


Un deadlock implique toujours (au moins) 2 locks, donc généralement 2
variables protégées chacune par un lock.

J'ai essayé
de trouver la variable concernée en annalysant la pile des threads
mais ai rien trouvé... Ma solution temporaire (et j'en suis pas
fier!) est SetProcessAffinityMask(..).


Beurk!

Pour ce genre de choses, WinDbg (téléchargable librement chez MS) est très
bien. Son IHM et son ergonomie sont ignobles (à, le bon vieux temps de *nix!
;-), mais une fois que tu maîtrise l'outil, il propose des tas d'aides très
utiles, du genre dumpter toutes les sections critiques du code en indiquant
pour chacune quel est le thread qui la tient (si aucun).

Sinon, il y a les outils "artillerie lourde" très chers et délicats à
prender en main, mais très efficaces, comme VTune d'Intel (l'outil Thread
Checker très exactement). Compuware (BoundsChecker, etc...) doit ausi avoir
quelque chose pour les deadlocks

Arnaud
MVP - VC
Poster une réponse
Anonyme