La boucle de message provoque une commutation de thread ?
3 réponses
Den
Bonjour,
Pour implémenter des sockets non bloquants dans un thread, je dois
incorporer une boucle de message classique (peekmessage, dispatchmessage).
Or ces instructions (peekmessage par exemple) semblent clairement provoquer
une mise en sommeil du thread courant, un peu à la manière de l'antique
"yield" de windows 3 ! Et cela même si le thread en question est de priorité
maximale.
Ce qui pourrait passer inaperçu dans la plupart des applications est dans
mon cas plutôt génant. Les sockets gérés dans le thread permettent d'envoyer
des requètes modbus/tcp qui exigent une bonne régularité. Or, si j'obtiens
un "temps de cycle" de ces requètes en général autour de 30 ms, cela peut
parfois monter à 300 ms, voire 500 ms !
Ce temps correspond d'ailleurs bien au temps d'exécution mesuré de
peekmessage...
Sachant qu'en enlevant la gestion des messages (et donc des sockets) le
temps de cycle des actions du thread ne dépasse plus 20 ms, je veux croire
qu'il y a un espoir d'amélioration...
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
Dominique Vaufreydaz
Bonjour,
Ce temps correspond d'ailleurs bien au temps d'exécution mesuré de peekmessage...
Sachant qu'en enlevant la gestion des messages (et donc des sockets) le temps de cycle des actions du thread ne dépasse plus 20 ms, je veux croire qu'il y a un espoir d'amélioration...
Oui, parceque tu passes par tout un mecanisme de communication interne, et ca te penalise...
Perso, je tenterait un bon vieux select des famille sur une beta socket a la posix. Pour faire. Si select te dis qu'il n'y a rien a faire, tu fais autre chose.
Par contre, le soucis c'est que je n'ai aucune idee de l'implementation de select et ne suis pas sur d'augmenter tes perfs. Mais reste qu'on ne part pas dans un enchevetrement d'appel de procedure pour traiter et dispacher le message a qui de droit.
Une idée. Doms.
Bonjour,
Ce temps correspond d'ailleurs bien au temps d'exécution mesuré de
peekmessage...
Sachant qu'en enlevant la gestion des messages (et donc des sockets)
le temps de cycle des actions du thread ne dépasse plus 20 ms, je
veux croire qu'il y a un espoir d'amélioration...
Oui, parceque tu passes par tout un mecanisme de communication interne,
et ca te penalise...
Perso, je tenterait un bon vieux select des famille sur une beta socket
a la posix. Pour faire. Si select te dis qu'il n'y a rien a faire, tu fais
autre chose.
Par contre, le soucis c'est que je n'ai aucune idee de l'implementation
de select et ne suis pas sur d'augmenter tes perfs. Mais reste qu'on ne
part pas dans un enchevetrement d'appel de procedure pour traiter
et dispacher le message a qui de droit.
Ce temps correspond d'ailleurs bien au temps d'exécution mesuré de peekmessage...
Sachant qu'en enlevant la gestion des messages (et donc des sockets) le temps de cycle des actions du thread ne dépasse plus 20 ms, je veux croire qu'il y a un espoir d'amélioration...
Oui, parceque tu passes par tout un mecanisme de communication interne, et ca te penalise...
Perso, je tenterait un bon vieux select des famille sur une beta socket a la posix. Pour faire. Si select te dis qu'il n'y a rien a faire, tu fais autre chose.
Par contre, le soucis c'est que je n'ai aucune idee de l'implementation de select et ne suis pas sur d'augmenter tes perfs. Mais reste qu'on ne part pas dans un enchevetrement d'appel de procedure pour traiter et dispacher le message a qui de droit.
Une idée. Doms.
Cyrille Szymanski
"Den" wrote in news:43f0bcb5$0$19719$:
Pour implémenter des sockets non bloquants dans un thread, je dois incorporer une boucle de message classique (peekmessage, dispatchmessage).
Il y a en gros 3 méthodes pour gérer des sockets non bloquantes :
1. select() comme le suggère Dominique. Les limitations (entres autres) : pour win32 cette api utilise une liste chaînée pour déterminer la liste d'attente ce qui pose problème s'il y a beaucoup de sockets à surveiller.
2. IO Completion Ports (iocp) : beaucoup plus performant et moins compliqué qu'il n'y paraît. Un exemple pratique http://www.developerfusion.co.uk/show/2498/1/
3. Les messages windows : je n'aime pas du tout cette approche car elle a tendance à casser la séparation IHM / logique.
Il est possible de se faire sa propre implémentation non bloquante si l'une des techniques ci-dessus ne convient pas.
-- Cyrille Szymanski
"Den" <toto@titi.com> wrote in
news:43f0bcb5$0$19719$8fcfb975@news.wanadoo.fr:
Pour implémenter des sockets non bloquants dans un thread, je dois
incorporer une boucle de message classique (peekmessage,
dispatchmessage).
Il y a en gros 3 méthodes pour gérer des sockets non bloquantes :
1. select() comme le suggère Dominique. Les limitations (entres autres) :
pour win32 cette api utilise une liste chaînée pour déterminer la liste
d'attente ce qui pose problème s'il y a beaucoup de sockets à surveiller.
2. IO Completion Ports (iocp) : beaucoup plus performant et moins compliqué
qu'il n'y paraît. Un exemple pratique
http://www.developerfusion.co.uk/show/2498/1/
3. Les messages windows : je n'aime pas du tout cette approche car elle a
tendance à casser la séparation IHM / logique.
Il est possible de se faire sa propre implémentation non bloquante si l'une
des techniques ci-dessus ne convient pas.
Pour implémenter des sockets non bloquants dans un thread, je dois incorporer une boucle de message classique (peekmessage, dispatchmessage).
Il y a en gros 3 méthodes pour gérer des sockets non bloquantes :
1. select() comme le suggère Dominique. Les limitations (entres autres) : pour win32 cette api utilise une liste chaînée pour déterminer la liste d'attente ce qui pose problème s'il y a beaucoup de sockets à surveiller.
2. IO Completion Ports (iocp) : beaucoup plus performant et moins compliqué qu'il n'y paraît. Un exemple pratique http://www.developerfusion.co.uk/show/2498/1/
3. Les messages windows : je n'aime pas du tout cette approche car elle a tendance à casser la séparation IHM / logique.
Il est possible de se faire sa propre implémentation non bloquante si l'une des techniques ci-dessus ne convient pas.
-- Cyrille Szymanski
Den
Merci beaucoup pour les réponses.
La solution la plus simple à mon problème a été de remplacer les messages par des événements, et donc à utiliser WSAEventSelect au lieu de WSAAsyncSelect. Plus aucun problème.
Amicalement Denis
Merci beaucoup pour les réponses.
La solution la plus simple à mon problème a été de remplacer les messages
par des événements, et donc à utiliser WSAEventSelect au lieu de
WSAAsyncSelect. Plus aucun problème.
La solution la plus simple à mon problème a été de remplacer les messages par des événements, et donc à utiliser WSAEventSelect au lieu de WSAAsyncSelect. Plus aucun problème.
