Thread ?Résolu

Question

Hi dudes,

Voila, jusqu'à présent, j'avais pas besoin de threader, donc je me posais pas énormémemnt de questions sur le sujet... et là... je me trouve confronté à la necessité de threader. 
C'est plus une obligation morale qu'un impératif, en fait. Vue la future plateforme cible pour le prog (Epia DP310) je me dis qu'en threadant au max ce qui peut l'être, ca va équilibrer la charge sur les procs, donc c'est plus propre, sachant que sur une EpiaDP310 (biproc), ceux-ci ne sont pas des foudre de guerre. Qui peut le plus pouvant le moins, ca tournera encore mieux sur un core2duo....

Une form est-elle une entité threadée à la base ? Je veux dire, si je crée un prog avec N forms permanentes, ai-je N threads ipso facto ?

J'ai lu le tuto ici également, auriez-vous des liens vers d'autres tutos ?

Merci d'avance.

cs_Loda · Accepted Answer

re,

"deux programmes (et donc deux threads)"
dsl, mais deux programme c'est deux process. et ça me semble plus simple de faire deux thread que deux process. 
C'est intéressant de faire deux PROCESS (application) si tu n'as pas besoin de l'affichage en premanance. tu laisse le process d'acquisition et de traitement tourner, et tu ne charge l'affichage que lors tu en as besoin. (et l'affichage vas lire un memorymap ou équivalent). C'est le même genre de system que pour configurer des services.

WhiteHippo a raison, tu gagne avec les thread si t'en a un nombre raisonnable. Si t'en a bcp, tu perd!

"je ne compte pas en avoir plus de 3 en tout, grand maximum." : très bien. N'oublie pas de regler les priorité !
Tu peux en avoir 4: genre un pour les acquisition lente, un pour les rapide, un pour les calculs sur les acquisition et le principal (affichage). Si els calculs sont rapide, tu peux les faire dans le thread d'acquisition.
(n'oublie pas que windows n'est PAS déterministe) sit u as besoisnd e rendre windows déterministe (ie: pour du Real time) il existe des trucs. (j'avais fait des recherche la dessus pour mon travail de diplôme. demande moi si jamais)

POur le debug, Tu peux faire une version avec un seul thread (ie: sans thread) qui fait une seul choses. En premier, disons l'acquisition, puis une fois qu'il marche bien, de faire le reste. Pour aller loin, il faut y aller par étape. (mais je pense que tu le sais déjà, non?)

Tu m'as l'aire d'avoir toute les chances de très bien t'en sortir. (Debug par log, se documenter avant de commencer, ...)

Un ou deux trucs:
-dérive la class TTHread de base pour ajouter des fct de debug/log

- nomme tes thread pour le debug. (ajout un champs fThreadName)
{$IFDEF DEBUG}
type
  TThreadNameInfo = record
    FType: LongWord;     // must be 0x1000
    FName: PChar;        // pointer to name (in user address space)
    FThreadID: LongWord; // thread ID (-1 indicates caller thread)
    FFlags: LongWord;    // reserved for future use, must be zero
  end;

procedure SetName(const Name:String);
var
  ThreadNameInfo: TThreadNameInfo;
begin
  ThreadNameInfo.FType := $1000;
  ThreadNameInfo.FName := PAnsiChar(@name[1]);
  ThreadNameInfo.FThreadID := $FFFFFFFF;
  ThreadNameInfo.FFlags := 0;
  try
    RaiseException( $406D1388, 0, sizeof(ThreadNameInfo) div sizeof(LongWord),
      @ThreadNameInfo);
  except
  end;
end;
{$ENDIF}

procedure TMonCustomThread.Execute;
begin
  inherited;

  {$IFDEF DEBUG}
  SetName(fThreadName);
  {$ENDIF}
end;

pour catcher les exception dans un thread:

procedure TMonCustomThread.DoTerminate; (override)
begin
  inherited;

  if Assigned(FatalException) then My_ProcessUnhandeledException(self,FatalException as Exception);
// tu peux faire la meme choses dans le event OnTerminate. mais pour une class de base...
end;

Si t'as des problèmes pratiques, demandes nous.

bon code,

Loda
<hr size="2" width="100%" />Se poser les bonnes questions est le premier pas pour trouver les bonnes réponses.

florenth · Answer

Salut,

Pour répondre à ta question, non, tu n'auras pas autant de threads que de forms.
Pour une simple raison: toutes les fiches doivent tourner dans le thread principal, sinon Delphi gère mal les messages Windows et c'est la galère.

D'ailleurs, je ne sais même pas si c'est possible avec d'autres langages.

Tu n'auras donc qu'un thread peu importe le nombre de fiches.
Par contre, si tu veux effectuer plusieurs choses à la fois, tu vas devoir "threader", càd créer un dérivé de TThread et effectuer les actions dedans.

Attention cependant: contrairement à une application mono-thread, tu vas devoir te préocuper de synchronisations entre tes nouveaux threads et le thread principal (pour le mise à jour de la fiche par exemple) car tu ne peux pas avoir plusieurs threads qui utilisent le même espace mémoire en même temps.

En gros: les threads, c'est du gros. Mais ne crois pas pour autant que tout va devenir plus rapide.

++
Flo

cs_Loda · Answer

salut, les thread ont deux principaux avantages: - faire en "background" les calculs long, sans bloquer l'interface utilisateur. - pour les communication réseau (écoute de port, ...)

pour pouvoir "threader" un truc, ce doit être un minimum indépendant. tu ne peux pas thread une fiche de ton prog prise plus ou moins au hasard. Les thread sont intéressant seulement si la function est très indépendante. plus tu doit synchroniser, moins c'est intéressant niveau perf. note que créer un thread n'est pas gratuit. ça coute du temps et des ressource. De manière général, un thread transformera des donnée. (tableau à tableau, param à bitmap, ..) je confirme, ne manipule pas de fiche dans des threads . ceci inclue les dialog. (ie: pour afficher une message depuis un thread, tu doit envoyer le texte à ton thread principale qui. lui, l'affichera. sinon c'est la merde, t'as des dlg au taille fantaisistes et autre problème similaires.) note aussi que la prog parallèle est presque une science à part. Aussi le débug de thread est très très difficile. (et delphi support très mal les break point dans les thread). Aussi, il est souvent impossible de reproduire une erreur liée au thread (AV, ..). les thread en Delphi functionne sur le même principe que dans d'autre language. cherche des tuto sur le net ! bon thread ! Loda

Se poser les bonnes questions est le premier pas pour trouver les bonnes réponses.

florenth · Answer

"et delphi support très mal les break point dans les thread"
=> C'est vraiment galère d'ailleurs. Heureusement, dans TurboDelphi, ça va déjà bien mieux mais c'est pas encore ça ...

DeltaFX · Answer

Merci. Je me doute que c'est du gros, et c'est d'ailleurs ce qui m'interresse : une partie du code (ce que je pense threader) doit discuter avec le hardware en permanence (carte interface) + systeme de positionnement=> fusion de capteur. Donc sur le papier je me retrouve avec a priori N Thread pour zieuter les différent hardwares (et tagguer les données par un timestamp) et un N+1ieme thread qui lui me fera un kalman du bigntz, et remontera les infos fusionnées dans le prog principal. Chacun avec des echelles de temps différentes, donc forcement des barrieres de synchro. Sous nunux je me torturerais moins, je m'interresserais direct a javaRT, mais...... c'est du zindoz, j'ai pas le choix.

Florenth, c'est quoi un breakpoint ?

WhiteHippo · Answer

Bonsoir

Et pourquoi pas tout simplement deux programmes (et donc deux threads) : Le principal et un secondaire chargé de la communication avec tous tes cartes d'interface. Le programme principal accédera aux données lues par le programme de communication via un filemapping. Quoi de plus simple ?? 

N.B. Tu pourras par ailleurs modifier la priorité du programme de communication.

P.S. "N Thread pour zieuter les différent hardwares" Ce n'est pas une bonne solution que de multiplier les threads !! 

Cordialement. 
<hr />"L'imagination est plus importante que le savoir." Albert Einstein

florenth · Answer

Le breakpoint, c'est quand tu cliques dnas la marge de l'éditeur: la ligne sélectionée apparait en rouge (sauf si tu as changé la couleur) et quand l'instruction surlignée est executée, Delpih passe en mode pas-à-pas et donc tu utilises F8 et/ou F7 pour avancer dans le programme. 

C'est très pratique pour débugger, surtot que tu peux créer des points de suivi pour vérifier que les différentes variables de ton application ont bien la bonne valeur au bon moment ...

Mais dans les threads, il as$rrive que ça plante ... snif !

DeltaFX · Answer

Whitehippo : oui, j'y ai pensé mais alors je me heurte a un problème de communication. Quand le pc se met en veille profonde (s3 ou S4) sur une décision de mon appli, pour parer au aléa windozien (genre pas de redétection des periphs usb à la sortie de veille) avant de s'endormir j'execute dans chacune des forms de l'appli une fonction PrepareToSleep qui selon le cas va se déconnecter des cartes  et hubs USB, fermer les ports série,tout ça. Si je splitte l'applic avec une communication par segment mémoire partagé, ca va être la mort pour avoir un truc réactif, et là le débug serait bien plus ardu (peut-on avoir 2 progs qui tournent en meme temps dans l'IDE, et pouvoir surveiller les deux en meme temps ? )

Je sais que zindoz limite a 16 le nb de thread, mais je ne compte pas en avoir plus de 3 en tout, grand maximum.

Quand au débug, je le ferai peut-etre pas en live, mais en ayant une log pour chaque thread, avec des timestamp. L'important est que quand le code de fusion des données tourne pour recalculer une position/vitesse estimée fiable, il doit intégrer :
- les n données des accéléromètres stockées pendant 1 seconde à 20Hz
- les m donnée des capteurs de rotation des chenilles pendant 1 seconde a 15 Hz ainsi que les clinomètres à la meme fréquence

et donc vider les buffers des threads en question. Je suis parti pour utiliser des verrous.

WhiteHippo · Answer

"Si je splitte l'applic avec une communication par segment mémoire partagé, ca va être la mort pour avoir un truc réactif..." C'est à dire ??? En vitesse de traitement ou bien en maintenance à long terme ?

"le débug serait bien plus ardu" : Faux car une fois ton appli de communication développée tu ne t'en occupes plus. Elle se résumera alors à un programme qui stockera des données dans une zone mémoire. Et tu pourras te concentrer sur le programme principal et le traitement des dites données.

"peut-on avoir 2 progs qui tournent en meme temps dans l'IDE, et pouvoir surveiller les deux en meme temps ?" Si tu lances le programme de communication à partir du programme principal, celui ci sera "vu" comme un processus engendré et donc tu pourras le deboguer (si option cochée dans les options du débogueur)

Cordialement. 
<hr />"L'imagination est plus importante que le savoir." Albert Einstein

cs_rt15 · Answer

Salut,

Pardon de pourrir le topic, mais je suis intéressé par les trucs de loda pour faire du temps réel sous windows. Autre que gestion de priorité et autres fermetures de processus bien sûr... Surtout si ça parle de ring 0.

Tu peux détailler un peu Loda svp ?

cs_Loda · Answer

@ rt15:

ouai, pas de blem. ce soir, je vais tacher de prendre 5min pour remettre la main sur mon rapport.

A+

Loda

Ps: la gestion de priorité ne permet PAS de faire du temps réel. Au cas ou cela ne serait pas clair pour toi, le temps réel n'est pas une question de vitesse mais de determinisme. (un system temps reel peut très bien est très lent)
<hr size="2" width="100%" />Se poser les bonnes questions est le premier pas pour trouver les bonnes réponses.

cs_Loda · Answer

re, envoie mon ton adresse mail en MP. je t'enverais une copie de la partie qui t'intéresse.

le context de mon rapport: j'étais chargé de porter du code 1131 (automate) sur une cible temps réel embarquée travaillant avec un prog Delphi et RT-OS 32. version courte de la section "choix de l'OS":

Linux RT + Kylix BlueCat Linux et LynxOS (un Unix-like) de http://www.lynuxworks.com/ ainsi que RTLinux et miniRTL (bootable sur floppy) (voir http://www.linuxdevices.com/ links/LK8662675028.html pour quelques informations générales.

windows CE ( /!\ debuger delphi ne focntionne pas bien sur win CE (utilise des fct non documenté de win)

windows XP avec Venturcom RTX Aucune version de windows n’est prévue pour faire du Temps Réel Hard. Articles parlant de l’usage de RTX avec Windows XP : http://msdn.microsoft.com/ Rechercher : « Hard Real-Time with Venturcom RTX on Microsoft Windows XP and Windows XP Embedded ». licenc : env. 600CHF / machine Rien n’est prévu pur utiliser Delphi avec (les API de) RTX. En effet, RTX est fait en C Ansi.

windows XP embedded Il présente la majorité des avantages de XP normal, sans en avoir les plus gros défauts. On peut brièvement citer les points suivants : RTX fonctionne aussi sur XP embedded. noyau personnalisable licence runtime : 90$

A+ Loda

Se poser les bonnes questions est le premier pas pour trouver les bonnes réponses.

DeltaFX · Answer

Loda, a propos du RT sous zindows, y a pas des gars qui travaillent sur BOSSA qui envisagent de porter ca sous XP.

Sachant que du RT Hard sous zindowz ( en sousw98 en prime :D mdlol) c'est pô la peine, je tag les lectures des capteurs par un timestamp ( un gettickcount avant, un autre apres, on moyenne et zou), apres ya juste des maths a mettre en jeu pour un kalman intelligent.

cs_Loda · Answer

re,

BOSSA ? connais pas. je sais pas. J'avais fait ces recherche y a un peu plus qu'une année.

disons, que si t'as pas besoin de RT hard, tu peux proceder comme suite:
- pas de reseau (très important)
- pas d'antivirus (évident)
- pas de firewall (ou autre cochonnerie similaire)
- virer tout les process inutile (java update, et autre bouffeur inutile de cpu/ram)
- mettre ton process d'acquisition en très haute priorité (outemps réel si t'es courageux)
- taper sur les user qui tente d'utiliser le PC
- et prier pour les variation soit dans tes marges de tollerance.

Aussi si tu fait du calcul de vitesse uniquement, tu n'as peux être pas besoisn de temps réel hard, mais seulement d'une bonne mesure de temps. Rappelons que gettickcount continue de s'incréemener lorsque le process n'as pas la main!

je connais pas tes conditons, mais tu peux aussi dédier (une partie) du calcul et l'acquisition sur une carte hardware. et plus besoin de temps réel sur windows. seulement d'un process qui t'affiche les resultats.

sinon, y a des distrib de linux RT qui sont bootable sur floppy (si si t'as bien lu)

A+

Loda
<hr size="2" width="100%" />Se poser les bonnes questions est le premier pas pour trouver les bonnes réponses.

DeltaFX · Answer

Le PC ne fera tourner qu'une appli (celle en question), pas de services, et pour l'instant l'appli tourne fluide sur un k6-2 450 MHz.

Effectivement je n'ai pas besoin de RTHard, mais de savoir précisement quand les mesures ont lieu, puisque j'integre les accélérations (2 fois), les vitesses (1 fois) pour obtenir une variation de position et la confronter avec un systeme de positionnement absolu.

Dans chaque thread de mesure je compte faire:

...
var Stamp:integer;
...

Stamp:= GetTickCount;
Card0.ReadAllDigital(A,B);
Stamp:=0.5*(Stamp+GetTickCount);
...

La question est de savoir comment faire empecher le thread de se faire préempter par un autre truc le temps d'exécuter les 3 instructions ci-dessus ?


Je n'ai pas les compétences pour concevoir une carte dédiée à mes besoins, donc je compose avec l'existant, c.a.d. accélérometres 2D en USB de chez phidget, et K8061 de chez Velleman. ( pas de drivers sous nux pour ces betes là)

florenth · Answer

"La question est de savoir comment faire empecher le thread de se faire
préempter par un autre truc le temps d'exécuter les 3 instructions
ci-dessus ?"

Tu peux utiliser une section critique pour bloquer les autres threads d'accéder à l'espace mémoire que tu utilises, à condition que ce soit faisable (je ne sais pas comment foncitonne ta méthode ReadAllDigital).

cs_Loda · Answer

Les sections critiques protègent un groupe d'instructions. cela garantie que ce group est exécuté que par un seul thread à la fois. c'set utile, pas exemple, pour modifier un group de var global qui doivent rester cohérente. Le but est, lorsque ton thread se fait premempter dans ce group d'instruction, que les autres thread qui auraient la main ne puisse pas lire un état incohérent ou te vandaliser tes var global. t'aura besoin d'une section cirtique entre ton thread d'affichage/calcul et celui d'acquisition (pour ne pas calculer avec la moitier des nouvelles valeurs et la moitier des anciennes) il y a aussi TMultiReadExclusiveWriteSynchronizer et d'auter similaire. Mais, d'aucun façon, tu n'empeche la préemption avec une section critique.

comment empêcher la preemption de process/thread sur XP, ça j'en ai aucune idée. cherche "disable preemption xp" tu trouverra peut-être qqch. rappel toi aussi, que l'OS change entre les process et que chauqe process change entre ces propres threads. (ce qui veut dire que lors que ton process reprend la main, il n'est pas garantie que tout ces thread ait la main durant son quantum de temps) Fait bien cette différence: entre le changement de context entre process et entre therad ! "l'appli tourne fluide" , c'est bien, mais cela neveut psa dire qu'elle ne vas pas se faire préempter au mauvais moment. Une autre approche serait de d'ignorer les valeur calculée qui trop loin des précédentes calculs. Ou d'envoyer ta consigne en te basant sur une moyen de tes mesures. tu limiterais l'impact d'une erreur (mais augementerais ton delai de réaction). bonne chance, Loda PS: Je sais pas qu'elle est ton budget et la fiabilité dont tu as besoin, mais RT-OS n'est pas si cher à la fin et il tourne sur une config très légère. (genre P133Mhz 64Mo sans prob.) PS2: je ne comprend pas l'extrait de code que tu nous a posté. Tu veux mesurer le temps nécessaire à la mesure (ie: l'appel a reaAllDigit).. ?!?? En plus je suppose que tu veux dire "Stamp: =0.5*(GetTickCount - Stamp);" ps3: si tu laisse le pc touner en permanence avec ta lecture de carte, tu doit gérer le cas ou le gettickcount passe par zéro. (ie: après ~50 jours d'exécution je crois) (oui je pense a ces détails pourrit, mais avant je travaillait dans le pilotage de machine qui tournaient en 3x8)

Se poser les bonnes questions est le premier pas pour trouver les bonnes réponses.

DeltaFX · Answer

Donc si j'ai bien compris, sous zindows, impossible d'empecher qu'un thread system préempte moes threadde mesure..... bon ben c'est du zindoz :D

Le readAllDigital est fournit par la DLL qui commande la carte k8061.

Stamp:=0.5*(Stamp+GetTickCount); c'est bel et bien le code que je veux. 

En gros ca revient à faire : il était 17h43min20s avant la lecture, il est 17h43min22s juste apres la lecture donc en gros on dit que la lecture à eu lieu vers 17h43min21s. 

Tu as raison j'ai omis la ligne qui calcule la durée de l'opération. Ce n'est qu'une approche, mais en cas de prémption, si le temps de mesure excede une valeur qui reste à définir, ca me permet de pondérer la "véracité" de cette info lors du calcul de position.

Mathématiquement parlant, j'ai dérivé les équations du mouvement avec les incertitudes spatiales et temporelles, et j'integre les données d'accélération /vitesse via une bricole type algo Runge-Khutta4, avant de passer par un filtre de Kalman pour comparer avec un système de positionnement absolu type gps, ou triangulation par balise. ( avec un résulat à sortir 1 fois par seconde, donc avec une machine suffisament descente, y a de la marge).

La plateforme cible tournera sous win98se, voir win2kSP4 car j'ai mes licence pour ces 2 trucs. XP euhhhhhh pas les sous, pas envie pour l'instant. Et nux, pas envie et pas les compétences pour l'instant.

Un jour (lointain) je migrerai tout en JavaRT sous un linux quelconque.

cs_Loda · Answer

re,

"Donc si j'ai bien compris, sous zindows, impossible d'empecher qu'un thread system préempte moes threadde mesure..... bon ben c'est du zindoz :D"

pas tout a fait. Ne confond pas process et thread ! et j'ai seulement dit que JE ne savais pas le faire. (du moisn sans un truc genre RTX). J'ai jamais dit que c'téait impossible. peut-être que tu peux jouer avec les interruption ou qqch comme ça.

De plus, ce genre de manip n'est, a ma connaissance, possible que sur des system RT.

"En gros ca revient à faire : il était 17h43min20s avant la lecture, il est 17h43min22s juste apres la lecture donc en gros on dit que la lecture à eu lieu vers 17h43min21s."
Ok. j'avais pas compris le but. dsl.
Et ta durée moyen de lecture? t'as un orde de grandeur? parceque si c'est faible tu peux "corriger" un eventuel probleme de préemption grace a cela !

win98 ?!? sans pouvoir te l'argumenter, je te le déconseille très vivement pour de la production.

bon, je vais te laisser te débrouiller depuis là. parceque je sais pas bcp de truc en plus qui pourrait t'aider.

en dernier, je me recommande, fait bien la différence entre thread et process.
aussi, renseigne toi un peu sur les différentes mtéhodes d'ordonnancement de thread/process. ça t'aideras a avoir une meilleur vu d'ensemble.

bon code !

Loda
<hr size="2" width="100%" />Se poser les bonnes questions est le premier pas pour trouver les bonnes réponses.

DeltaFX · Answer

Wé oops abus de langage j'aurais du écrire process system. T'inquiètes pas, tes infos recoupent ce que j'avais glané comme connaissances à propos de windoz.

Durée moyenne de lecture : oui Ca tourne autour de 7ms, ca sera pris en compte

C'est du loisir donc meme win98 suffit :)

Merci.

DFX

aroslide · Answer

c interessant tout ça moi aussi ça m'interesse en ce moment je suis planté sur un serveur multithread mais il plante à 150 utilisateurs. en socket non bloquant je vois pas comment faire je profite de la discussion pour avoir des informations par contre je veux absolument créér un thread par utilisateur l'application repose la dessus ... 
Merci si il y en a que ça interesse sinon tant pis je continuerais a faire mes recherches seul. 

@+

Thread ?

21 réponses

Votre réponse

Discussions similaires