Logo GNT
Actualités Tests & Guides Bons Plans
Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11
Entraide Développement Développement Environnement Microsoft Problème de multithreading

Problème de multithreading

12 réponses
Avatar
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.
Signaler un problème avec ce contenu

10 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
1 2
Avatar
Vincent Burel
"Grég" wrote in message
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
Avatar
Grég
"Vincent Burel" a écrit dans le message de
news: 43ddd3f7$0$19701$

"Grég" wrote in message
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...
Avatar
Chevalley J.-C
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" a écrit dans le message de
news:43de3e39$
"Vincent Burel" a écrit dans le message


de
news: 43ddd3f7$0$19701$
>
> "Grég" wrote in message
> 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...




Avatar
Vincent Burel
"Chevalley J.-C" wrote in message
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
Avatar
Paul Bacelar
"Vincent Burel" wrote in message
news:43de611c$0$21258$

"Chevalley J.-C" wrote in message
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++
Avatar
Vincent Burel
"Paul Bacelar" wrote in message
news:drm397$s6n$
"Vincent Burel" wrote in message
news:43de611c$0$21258$
>
> "Chevalley J.-C" wrote in message
> 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
Avatar
Arnaud Debaene
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
Avatar
Chevalley J.-C
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
Avatar
Vincent Burel
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" wrote in message
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





Avatar
Arnaud Debaene
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
1 2