Discussion :

[molox]

Salut,

Déjà un grand bonjour à tous.
J'ai un soucis de réactivité avec un thread, j'ai trouvé un moyen de le contourner probablement le problème mais ce n'ai pas une solution très élégante

* Description :
L'application est du W32 natif (C) compilé sur VC2008. Elle doit gérer un capteur de pression très finement et prendre des mesures à des instants très précis par une demande provenant du réseau. L'application est donc connecté a un serveur. (Mode client/serveur UDP avec des socket DATAGRAM)

* Architecture :
En gros, j'ai 3 threads de lancé :
- 1 thread "thread_recv", bloqué sur un recvfrom(), dès qu'un paquet arrive il est mis dans un spool, puis signal un evenement "evt_recu" et retourne a son recvfrom().
- 1 thread "thread_network", bloqué sur un WaitForMultipleObject, il attend le "evt_recu" (pour traiter traite le spool) et un evenement d'arrêt du thread.
- 1 thread "thread_sensor", bloqué sur un WaitForMultipleObject, il attend un evenement "evt_sensor_data" qui indique que des données sont prêtent dans un buffer (provenant du driver du capteur)

L'événement "evt_sensor_data" arrive toute les 32059 µs environs (32ms).
Le driver met à dispo un buffer qui contient des données sur 32 mesures (une toutes les millisecondes). une boucle traite donc ces 32 mesures
A chaque mesure traité, un compteur "sample_count" est incrémenté. (incrémenté toutes les millisecondes). A chaque événement "evt_sensor_data" le compteur est donc incrémenté en tout de 32.
(32 fois sample_count++ pour être précis)
Le thread "thread_sensor" ne met que 27 µs à traiter le buffer, puis attend 32ms le prochain buffer, etc...


* But
Mon but est de pouvoir, par l'intermédiaire du serveur, demander à 2 machines en même temps de m'envoyer leur valeur courante de "sample_count" pour connaitre le décalage temporelle entre les 2.

* Problème
J'ai implémenté cette mécanique, ca fonctionne, mais pas assez finement. En effet, lorsque j'envois la trame de demande du "sample_count" par le serveur, je récupère des valeurs multiple de 32 de la part des clients. (-32, 32, -64, 64, etc...) .
Je souhaite obtenir la valeur exacte du "sample_count", donc que mon thread réseau "préempte" mon thread "sensor"

* Précision
- J'ai déja essayé de "yielder" mon thread après chaque incrémentation de "sample_count" ( SwitchToThread() )
- J'ai mis des priorité plus haute sur mes threads reseaux THREAD_PRIORITY_HIGHEST, j'ai même essayé THREAD_PRIORITY_TIME_CRITICAL
- Je n'ai pas protégé mon compteur "sample_count" car je ne fais qu'un simple "sample_count++;" qui me semble t'il est une opération atomique ?

* Piste de résolution
J'ai l'impression que mon traitement est trop rapide 27 µs pour traité les données de 32 ms temporelle, je pense que mes temps de bufferisation, spool et traitement de la requête réseau sont plus long que 27 µs.

Mon idées est de ralentir de thread entre chaque incrémentation du compteur et de yielder le thread.

Par exemple laissé bouclé pendant 200 µs entre chaque incrémentation soit 6.4 ms mangé sur le quantum, que mes thread reseau pourrait donc prendre la main durant ces laps de temps...
Par contre je devrais utiliser le QueryPerformanceCounter, car je ne vois pas comment attendre autrement, proprement 200µs (sur des machines a vitesse de proc différente.

* Questions :
- Mon raisonnement est t'il valable ?
- Est t'il courant de ralentir un thread ?
- N'y a t'il pas meilleur solution ?
- Si non avec vous une idées autre que QPC ou une boucle ASM pour attendre ~200µs (dans cette ordre de grandeur < 1 ms)

Merci d'avance pour vos conseils
Merci de m'avoir lu

Molox

[nicolas.sitbon]

Quel traitement fais tu sur tes mesures?

[molox]

Salut,

Merci de m'avoir lu.
Je fais des statistiques, régression linéaire, prédictions, transformée de fourrier... expliqué en détail sort de ce cadre, c'est assez complexe et spécifique, c'est expérimentale. Mais en tous cas, je met 27 µs pour traiter 32 ms temporelle.

Molox

[nicolas.sitbon]

Je demande ça car j'ai l'impression que tu passes trop peu de temps sur tes mesures pour justifier un thread dédié, tu dois perdre plus de temps en préemption qu'autre chose, il ne te serait pas possible de passer à un modèle complètement évènementiel? Je me doute que ça ne fera qu'empirer ton problème de décalage temporel mais mieux vaut régler un problème à la fois, il est clair que dans ton cas, tu ne passes clairement pas assez de temps cpu pour avoir la granularité que tu souhaites.

[molox]

Re,

Encore merci de te pencher sur mon problème...

Je demande ça car j'ai l'impression que tu passes trop peu de temps sur tes mesures pour justifier un thread dédié.

Je me pose aussi cette question, mais l'événement est tellement fréquent...

tu dois perdre plus de temps en préemption qu'autre chose,

C'est clair ! tu connais l'ordre de grandeur du temps de changement de context sur W32 ? (XP pro)

il ne te serait pas possible de passer à un modèle complètement évènementiel?

Tu veux dire au sens socket asynchrone et tous dans un même thread ?
Je vais essayer de repenser a ça.

il est clair que dans ton cas, tu ne passes clairement pas assez de temps cpu pour avoir la granularité que tu souhaites.

Ta remarque me rassure un peu, je ne me trompe pas dans ma logique déja.

Nicolas, Merci encore pour ton aide

Molox

[nicolas.sitbon]

tu connais l'ordre de grandeur du temps de changement de context sur W32 ? (XP pro)

Je ne le connais pas exactement, mais l'ordonnanceur est appelé toutes les 10ms en moyenne, tu comprends ainsi pourquoi tu ne peux avoir une granularité inférieur à 32 mesures.

Tu veux dire au sens socket asynchrone et tous dans un même thread ?

Absolument.

[molox]

Salut,

Je ne le connais pas exactement, mais l'ordonnanceur est appelé toutes les 10ms en moyenne,

C'est en moyenne 16ms le quantum alloué par XP (ou 30 en mode "arrierer plan"), je viens de le véfier sur plusieurs machine.
De plus un thread ne consomme pas forcément tout son quantum de temps.

tu comprends ainsi pourquoi tu ne peux avoir une granularité inférieur à 32 mesures.

La justement j'ai du mal expliqué mon truc, Car je travaille en temps décalé, référencé, d'ailleurs par exemple j'arrive a une granularité de + ou - 2 à 3ms en ralentissant mon thread (boucle de 800ms) même avec un quantum de 16ms.

Pour info c'est environs ~1 ms de changement de contexte de thread pour XP et Linux pour les processus les différence sont plus importante.
Donc voila ou est la véritable granularité

Merci pour tes idée

Molox

[nicolas.sitbon]

C'est en moyenne 16ms le quantum alloué par XP (ou 30 en mode "arrierer plan"), je viens de le véfier sur plusieurs machine.
De plus un thread ne consomme pas forcément tout son quantum de temps.

Le quantum varie de 10 à 16ms de NT à vista.

[Mac LAK]

Si tu dois passer largement sous la limite du quantum de temps "basique", je te suggère de te tourner vers les fibres...

Commence par MDSN : CreateFiber pour voir si cela peut résoudre ton problème, sinon tu risques de devoir attendre Windows 7 pour le faire.

[nicolas.sitbon]

Si tu dois passer largement sous la limite du quantum de temps "basique", je te suggère de te tourner vers les fibres...

Commence par MDSN : CreateFiber pour voir si cela peut résoudre ton problème,

Ah oui, pas idiot, je n'y avais pas pensé, néanmoins je pense toujours que le modèle évènementiel serait plus adapté dans son cas.

sinon tu risques de devoir attendre Windows 7 pour le faire.

Ah, tu m'intéresses, aurais tu eu vent de nouvelles apis?

[Médinoc]

Une incrémentation "simple" n'est pas atomique. Par contre, il y a la fonction InterlockedIncrement() qui peut t'aider...

[Mac LAK]

Ah oui, pas idiot, je n'y avais pas pensé, néanmoins je pense toujours que le modèle évènementiel serait plus adapté dans son cas.

Qui t'a fait croire qu'une fibre n'était pas évènementielle ?
Étant donné que TU décides de son scheduling, tu y fais ce que tu veux... Cf. MSDN : Using Fibers.

Ah, tu m'intéresses, aurais tu eu vent de nouvelles apis?

Oui, tu peux jeter un œil là-dessus :
- De façon générale, MSDN : Process and Thread Functions.
- Plus spécifiquement : MSDN : Thread Ordering Service Functions (Vista et plus).
- MSDN : User-Mode Scheduling Functions (Windows 7 et plus).

Attention toutefois : si tu utilises ces API, il faut impérativement penser à tester, en début de programme et/ou de setup, la plate-forme d'exécution afin de l'interdire sur les versions de Windows ne possédant pas ces fonctionnalités... Sinon, ça va faire boum, et ça peut faire très mal si ça pète en plein milieu d'une initialisation.
Ça doit être possible de définir ça directement à la compilation, je pense, dans les options du projet... Je n'ai jamais regardé spécialement ce point par contre, en général je blinde au niveau du setup, et j'utilise du code conditionnel à l'exécution au niveau du programme lui-même.

Une incrémentation "simple" n'est pas atomique. Par contre, il y a la fonction InterlockedIncrement() qui peut t'aider...

Une opération "++" est atomique sur une variable locale au thread. Elle ne l'est bien entendu pas sur une variable globale, partagée entre plusieurs threads, ou pire : partagée entre plusieurs processus.

Effectivement, dans ce cas, les fonctions "Interlocked*" sont à préférer. A noter qu'elles sont infiniment plus efficaces qu'une atomicité faite "à la main" (prise de mutex, incrémentation, relâche du mutex) car elles sont en fait de simples raccourcis pour des instructions du processeur, ce qui explique aussi leur aspect "abrupt" côté syntaxe.
Une incrémentation atomique par InterlockedIncrement ne prends guère plus de temps qu'un simple "++", surtout via les fonctions intrinsèques du compilateur...

[nicolas.sitbon]

Qui t'a fait croire qu'une fibre n'était pas évènementielle ?
Étant donné que TU décides de son scheduling, tu y fais ce que tu veux... Cf. MSDN : Using Fibers.

Je me suis mal exprimé, je parlais évènementiel dans le sens ou li n'y qu'un seul thread, qui gère tous les évènement. Même si c'est une fibre, il y a toujours changement de contexte.
Autrement, merci pour les liens.

[Médinoc]

Il y a beau y avoir changement de contexte, c'est toujours un seul thread.

[nicolas.sitbon]

Il y a beau y avoir changement de contexte, c'est toujours un seul thread.

bien sûr, c'est le principe même des fibres.

[Mac LAK]

Pas si ton recv() bloquant est, justement, dans le thread gérant les fibres... Là, pas de changement de contexte (hormis un swap de registres), donc gain de temps.

Il te suffit alors d'avoir assez de threads en attente d'une trame réseau pour gérer tout ça.

[nicolas.sitbon]

Pas si ton recv() bloquant

Heu non, faire un modèle full évènementiel avec des I/O bloquants n'a pas grand intérêt. Je suis conscient que c'est quelque chose que l'on rencontre plus sous Linux, mais niveau perf, et dans son cas, je suis certain que c'est le meilleur choix. On retrouve le même problème avec les web serveurs et les proxys, là encore, le modèle full évènementiel à largement demontrer sa suprématie sur le modèle multithread (ou multiprocess) (cf: lighttpd, haproxy, ...).

[Mac LAK]

Sauf que si j'ai bien compris son problème, l'OP cherche un temps de retournement minimal sur ces réceptions réseau, le reste de la machine ne faisant pas grand-chose de suffisamment important pour empêcher de coller ce point en haute priorité.

Dans ce cas, et parce que le temps de retournement est prioritaire par rapport à la charge CPU (ce qui est largement faux sur un serveur Web par exemple...), un thread par élément à surveiller avec sockets bloquants + fibres peut être largement supérieur, par le simple fait que ça réduit les couches logicielles entre l'arrivée de la trame et l'action finale ainsi que les changements de contexte.

Il ne faut par contre pas en faire une généralité, soyons bien clairs et insistants sur ce point !!!

[molox]

Salut à tous,

Déja milles merci pour vos conseils et idées.
J'ai regardé du coté des fibres, et reflechi longement a passer mon appli en monothread (evenementiel). J'ai aussi corrigé mon erreur de d'atomicité ++.

Depuis j'ai fais aussi fais des centaines de mesures et d'essais et en fais mon problème ne vient pas véritablement de la synchro des threads ou de dépassement de quantum, etc...

Pour simplifier :
Sur chaque client
* j'ai un thread qui recois régulièrement des événements qui indique qu'un buffer de 32 données est prêt. Ce buffer correspond a 32 mesures, 1 toutes les millisecondes.
Une boucle traite chaque échantillons, effectue des analyses statistiques et incrémente un compteur global (sample_count).
sample_count indique donc depuis combien de temps ce capteur a démarrer ses mesures en milliseconde. (et du même coup la dérive que je dois prendre en compte dans de futures calculs)
il faut au moins 32 ms a la carte d'acquisition pour remplir le buffer (un événement toutes les 32 ms) et il faut 20 µs au thread pour traiter ce buffer.


* j'ai un autre thread qui reçoi un "GET_CURRENT_SAMPLE" par un socket
Ce thread doit renvoyer le plus vite possible la valeur courante du sample_count au serveur.


Comme le thread du capteur met seulement 20µs pour incrémenter les 32ms de temps "réel", il va beaucoup plus vite que le temps même de traitement d'un évenement ou de mettre le paquet "GET_CURRENT_SAMPLE" dans le spool, les valeur "photographiée" au moment de la réception de la trame seront multiple de 32... ce que je constate malheureusement...

Pour etayer ma thèse, j'ai donc inséré, dans la boucle de traitement du buffer, une tempo de forcené de 900µs apres chaque echantillons. J'ai donc "calqué" le temps de traitement sur sa valeur temporelle "physique" 32 ms de données traitées en 32 ms

Et cette méthode fonctionne pas trop mal, mais elle ne me plait vraiment pas
beaucoup...

[Mac LAK]

Le problème, c'est que ton thread d'acquisition est en "retard" sur les acquisitions réelles, de 1 à 32 ms pour être précis... Le ralentir pour obtenir un décalage plus ou moins constant n'est pas vraiment une solution, sauf que tu vas "forcer" un décalage temporel constant au lieu d'un décalage temporel variable.

Donc, ton thread qui renvoie le "GET_CURRENT_SAMPLE" est lui aussi "en retard", qu'il soit multiple ou pas de 32... Si tu voulais une valeur "exacte", il te faudrait horodater la réception des 32 valeurs, et renvoyer une valeur extrapolée en fonction du timestamp de réception du "GET_CURRENT_SAMPLE" (formule : (timestamp de la demande - timestamp de la dernière trame) + dernier compteur)... Ce qui ne nécessite pas du tout de ralentir ton thread d'acquisition.