Discussion :

[Aragorc]

Bonjour
Je debute ds la programmation ac des threads et je cherche un moyen pour que 2 thread communiquent entre eux

J'ai un premier thread qui recupere des donnees a partir du port parallele et qui les affiche sur mon application
Et j'ai un deuxieme thread qui doit recuperer ces donnees, les mettre en memoire et les envoyer sur excel via une liaison ole
Mon probleme est que je ne sais pas comment partager une variable entre mon thread1 (qui est lance plusieurs fois, 1 pour chaque canal) et mon thread2, qui doit recuperer ttes les donnees pour les ecrire de maniere groupé

Je suppose qu'il existe une maniere toute simple de resoudre ce pb, mais jusqu'a present, je n'ai trouve de reponse nullepart

Cordialement Aragorc

[Philippe Gormand]

Salut.

Il faut utiliser une variable globale. C'est expliqué dans l'aide de DELPHI.

A+

[Aragorc]

merci pour l'aide, je crois que ca va bien m'aider

++

[Caine]

C'est un peu plus compliqué.

En effet, tu peux utiliser une variable globale, mais pour garantir son intégrité, tu dois synchroniser son accès en écriture et en lecture par mutex.

Sinon il y a un risque de lire ou d'écrire une variable dans un état indéterminé.

Par exemple, si le thread d'écriture fait un INC(var), en assembleur ça donnera 2 opérations. Si le thread 2 lit la var alors que seule la 1ère opération assembleur est effectué, il lira une valeur intermédiaire qui n'est pas forcément la valeur finale.

CreateMutex est ton ami

[Aragorc]

j'ai deja un mutex
etant donne que mon thread1 lit des donnees depuis un circuit electronique et je ne peux pas lire tous les canaux en meme tps
Createmutex est plus qu'un ami ds mon cas
Par contre, je me demandais si le mutex ne ralenti pas un peu l'execution du programme
Ai-je interet a 10 threads ac une partie de ses instructions qui verrouille le mutex, ou a repeter 10 fois ttes les instructions ds un thread?

[Caine]

Par définition, le mutex ne ralentis pas le système, ni l'appli.

Mais il permet de scheduler celle-ci, donc si le code est mal écris, il peut y avoir perte de performances.

Pour ta dernière question, il est difficile d'y répondre sans avoir le code, ou une estimation du nombre de lignes...

[Aragorc]

voici le code du premier thread, qui est lance 11 fois

procedure TLecture.Execute;

begin
Repeat

WaitForSingleObject(Mutexpuce,INFINITE);
sleep(vitesse); //evite une erreur ???
datalecture:=lectureTCL1543(canalbin);
Form1.data[canal]:=strtoint(floattostr(conversiondec(datalecture)*multip));
ReleaseMutex(MutexPuce);
Display.text:=floattostr(conversiondec(datalecture)*multip);
until terminated;
display.Text:='';
end;

En faite, pour l'instant, la vitesse d'execution est limitée par le sleep(vitesse) car pour une raison qui m'est inconnue, le progamme bug si je descend en dessous de vitesse=10....20 ????

Cela dit, je pense que le plus simple est de faire des tests en prenant aussi en compte la vitesse de ma puce electronique et celle du port parallele, mais vu le nombre de ligne, je pense que je m'embete un peu pour rien....
le seul avantage, c'est que je peux gerer chaque canal independament.... et encore

+++

[Caine]

Tu devrais éviter INFINITE et le remplacer par un Timeout, même grand.

En effet, ton code dans l'ensemle est-il assez robuste pour éviter un "deadlock", c'est à dire que le mutex ne soit jamais relâcher?

Quand tu dis que ça bugue, tu veux dire que l'appli se fige, c'est bien ça? Tu as donc probablement un deadlock.

De ce que j'en comprends, la lecture sur la carte à puce est synchrone, c'est peu être elle qui ralenti l'appli.

Sleep n'a aucune raison de faire planter l'appli. Sleep est surtout utile pour permettre au système de rerendre la main et de schéduler les processus et les threads.

J'ai déjà utilisé (très souvent), sleep(0) pour relâcher le quantum de temps système.

Soit le mutex n'est pas pris et bloque, soit la lecture ne se termine pas, seules pistes à mon avis.

[Aragorc]

en effet, tu avais raison, il arrivait un moment ou le mutex n'etais pas pris, il m'a donc suffit d'augmenter la zone qui retient le mutex pour resoudre ce probleme

voila, mon programme fonctionne assez bien pour une premiere version...

En tout cas merci pour ton aide, ca fais vraiment plaisir de savoir qu'il y a tjrs qq pour aider un novice dans la galere

+++ Aragorc

[edam]

En faite, pour l'instant, la vitesse d'execution est limitée par le sleep(vitesse) car pour une raison qui m'est inconnue, le progamme bug si je descend en dessous de vitesse=10....20 ????

regard votre code:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Display.text:=floattostr(conversiondec(datalecture)*multip);

et vor l'aide en ligne sur Synchronize

TThread.Synchronize
Exécute un appel de méthode dans le thread VCL principal.
Synchronize provoque l'exécution de l'appel spécifié de la méthode spécifiée par Method par le thread CLX principal, ce qui évite les conflits multithread. Si vous n'êtes pas sûr qu'un appel de méthode soit adapté à l'utilisation de threads, appelez-le depuis le thread CLX principal, en lui étant transmis par la méthode Synchronize.

L'exécution du thread est interrompue tant que Method s'exécute dans le thread CLX principal.

Remarque*: Vous pouvez aussi protéger les méthodes non sécurisées en utilisant des sections critiques ou le synchroniseur en écriture exclusive multi-lecture.

tu peut aussi utlisé des liste de type FIFO pour ne pas +ou - ne pas utlisé des mutex

[Aragorc]

excuse moi edam, mais j'ai un peu du mal a te suivre...
mes connaissances en programmation ne sont pas tres grandes et il y a un grand nombre de choses que je ne sais pas, dc qd tu parle ac des citations....ca m'aide pas

Si j'ai bien compris, tu me conseilles d'utiliser la propriete synchronize plutot que le mutex. c'est un peut etre un choix judicieux mais ne connaissant pas vraiment le fonctionnement de cette procedure, je peux pas te repondre

quant aux listes de type fifo, je n'ai aucune idée de ce que c'est

cela dis, je pense que je vais devoir revoir le fctnt de mon prog une fois que j'aurais fais des tests plus approfondis ac l''electronique qui va derriere

++

[Philippe Gormand]

Pardon de revenir sur mon message précédent, mais...

Utiliser une variable globale pour ton problème, le résoudrait d'un coup.
Ou alors je n'ai pas tout compris.

La méthode "Synchronise", c'est tout autre chose.

La meilleur méthode pour transmetre des valeurs entre Thread est l'utilisation de variables globales. C'est pourtant bien expliqué dans l'aide de DELPHI.

Ou alors, quelque chose m'échappe.

NB : Quelque fois, il est préférable de repartir du début pour bien cerner le problème

[Aragorc]

la variable global m'a permis de resoudre mon probleme, et de simplifier grandement mon code
Toutefois, je me demande pourquoi on utilise pas cette methode plus souvent
elle est bp plus simple a utiliser et permet d'eviter d'avoir a reatribuer les variables ds constructor du thread

......

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
constructor TLecture.Create(Acanal:integer;ADisplay:TEdit;Amultip:extended; Avitesse:integer);
begin
  FreeOnTerminate := True;
  inherited Create(Suspended);
 
Mutexpuce :=OpenMutex(MUTEX_ALL_ACCESS, True, 'MyMutex');
 
  Display :=Adisplay ;
  canal:=Acanal;
  multip:=Amultip;
  vitesse:=Avitesse;
 
.......

ce passage ne me parait pas tres logique, y'a t'il une autre methode plus 'rationnelle'


ensuite le topic a derive sur l'utilisation des mutex pour eviter que 2 threads accedent a la variable en meme tps

En effet, tu peux utiliser une variable globale, mais pour garantir son intégrité, tu dois synchroniser son accès en écriture et en lecture par mutex.

Sinon il y a un risque de lire ou d'écrire une variable dans un état indéterminé.

qd a la methode synchronize, n'ayant pas vraiment compris le message d'edam et ne connaissant pas vraiment cette methode, je ne peux pas t'eclairer


Pour ce qui est de l'aide, je dois pas savoir m'en servir correctement (ou alors j'ai pas assez insiste), mais le fait est que les explicatoin ne m'ont pas paru clair du tout

[DMO]

Salut,

Sychronize est l'intermédiaire à utiliser non pas entre deux threads que tu gères, mais entre un de tes threads et le processus principal, gérant la couche IHM. Tout accès à l'IHM doit se faire par un synchronize.

Le simple fait que les données doivent être accessibles à tous les threads qui en ont besoin (M. de La Palice n'aurait pas dit mieux), n'est pas suffisant, il faut synchoriniser les accès.

Il y a plusieurs méthodes pour synchroniser des threads, la plus radicale et efficace d'un point de vue protection, mais certainement pas la plus efficace d'un point de vue perf, est l'utilisation de sections critiques. Dans ton cas cela me semble inutile.

Par contre il faut bien réfléchir à quel objet de synchro utiliser, car selon le cas d'utilisation, le choix peut s'avérer super pratique, ou foireux... Tu trouveras de nombreuses descriptions des objets dispos sur le net.

Certains de ceux que l'unité SyncObjs n'a pas encapsulé l'ont été par les gars de la JCL dans l'unité JclSync (bon à savoir ).

J'écris cette réponse surtout pour appuyer la suggestion d'Edam qui me semble particulièrement judicieuse dans ton cas : immagine que tu ais x threads travaillant à la récupération des données, et 1 thread qui les traite.
Alors utiliser une liste (protégée) FIFO (First In First Out) me semble être une très bonne idée. Tous la remplissent, un seul la vide et la traite régulièrement dans un while NOT Empty do.

L'unité de Jcl te fournit des implémentations de telles listes (thread safe).

Bon courage.

[Caine]

Je sui d'accord avec le début.

J'écris cette réponse surtout pour appuyer la suggestion d'Edam qui me semble particulièrement judicieuse dans ton cas : immagine que tu ais x threads travaillant à la récupération des données, et 1 thread qui les traite.
Alors utiliser une liste (protégée) FIFO (First In First Out) me semble être une très bonne idée. Tous la remplissent, un seul la vide et la traite régulièrement dans un while NOT Empty do.

L'unité de Jcl te fournit des implémentations de telles listes (thread safe).

Bon courage.

Avec Delphi (professionnel du moins, pour le personnel, ça reste à vérifier) il y a bien plus efficace et sécurisé:TMultipleReaderOneWriters.

Un super mutex qui synhronise les lectures multiples avec un seul rédacteur, ce qui semble être ton cas.

De plus, NON une variable globale non sécurisée n'est pas suffisante ni sécurisée.

Un simple INC(VAR) prend 3 instructions assembleurs. Si un thread lit la variable au milieu de ces insctruction (déclenchées par un autre thread), l'intégrité du résultat n'est pas garantie.

[DMO]

Je sui d'accord avec le début.

Donc c'est déjà un bon début !

bien plus efficace et sécurisé:TMultipleReaderOneWriters.

Mon petit D6 Pro et moi-même ne connaissons pas TMultipleReaderOneWriters. Par contre si c'est de TMultiReadExclusiveWriteSynchronizer (ou TMREWSync pour son p'tit nom) dont tu veux parler, ça je connais. Il remplace souvent avantageusement des sections critiques et en effet, j'en préconise vivement, tout comme toi, son utilisation.

Maintenant, sous réserve que TMultipleReaderOneWriters ne soit pas une nouvelle classe de synchro que je ne connaitrais pas encore (alors je serais intéressé d'en savoir plus!), ce dont je voulais parler est une espèce de liste d'un fonctionnement rudimentaire (Enqueue, Dequeue) mais adéquat lorsqu'il s'agit de synchroniser deux (ou plus) threads dont l'un remplie et l'autre traite (donc vide).

Si c'est bien quelquechose dans le genre que souhaite faire notre ami, il va certainement refaire une espèce de liste lui-même, dont il protègera les accès grâce à un TMREWSync. Donc voilà, s'il veux ne pas s'embêter à le réimplémenter, il peut utiliser des classes déjà existantes : TJclQueue, TJclStrQueue (unit JclQueues), ou TJclStack, TJclStrStack (unit JclStacks). Les queues me semblent plus adaptées.

Espérant avoir apporté au débat, bon développement.

[Caine]

Bonsoir,

Oui il s'agit bien du composant dont tu parles, j'en avais oublié le nom, mais je savais que ça parlerais à quelqu'un.

Pour le reste, à lui de faire son choix.

[Aragorc]

desole d'avoir tant tardé à repondre...
Apres avoir lu vos suggestions, j'ai d'abord essaye la section critique
le gain de vitesse est assez impressionnant, mais il m'est alors impossible de synchroniser le thread qui traite les données ac ceux (11) qui recuperent les donnees
le thread qui traite les donnees les traite toutes en meme tps et doit attendre que les 11 threads aient finis

Ensuite j'ai essaye d'utiliser les listes proteges et les Tjclstrqueues, mais la vous etes bien au dessus de mon niveau
Si j'ai bien compris, un liste protegée permettrait a mes threads de la remplire sans risque de conflit, puis un autre thread pourrait detecter lorsqu'elle est pleine, et traiter les données
Apres avoir bien bataille, j'ai reussis a installer les composants jcl, et a cree un liste de type Tjclqueue, mais je suis incapable de l'utiliser, et je n'ai trouve aucune aide sur internet.
Un petit exemple, ac les principales commande, (ou alors un lien), m'aiderais beaucoup

Merci
+++

[hy00ga]

Biiiiiii .. les variables Globales c'est le mal incarné !!! C'est vrai que tu fais une var global et dans 99% des cas ca marche impec. Mais de temps en temps tu as une plantée, tu te tire les cheveux et PAF variable globale.

C'est le base de la programmation concurrente. Je vais essayer de faire un petit exemple pour mieux illustrer.

Soit une variable globale appelé A = 0
et 2 threads T1 et T2

T1 fait simplement A := A+1
et T2 aussi fait A := A+1

Tu te dis , a la fin A = 2 ? ET BEN NON !!

Sénario Normal :
T1 va chercher la valeur de A en mémoire (0) et le met dans un registre
T1 Incremente le registre (1)
T1 remet le contenu du registre dans la mémoire. (1)
T2 va chercher la valeur de A en mémoire (1) et le met dans un registre
T2 Incremente le registre (2)
T2 remet le contenu du registre dans la mémoire. (2)

Ce qui peux arriver de temps en temps
T1 va chercher la valeur de A en mémoire (0) et le met dans un registre
T1 Incremente le registre (1)
T2 va chercher la valeur de A en mémoire (0) et le met dans un registre
T2 Incremente le registre (1)
T2 remet le contenu du registre dans la mémoire. (1)
T1 remet le contenu du registre dans la mémoire. (1)

Résultat : A la fin Tu as 1 dans ta variable au lieu de 2 . Et c'est impossible a debugger car si tu le fas en pas a pas, tu ne tombera jamais sur ce scénario

Conclusion : JAMAIS DE VARIABLE GLOBALE

[DMO]

le thread qui traite les donnees les traite toutes en meme tps et doit attendre que les 11 threads aient finis

Tu donnes là une information supplémentaire non négligeable. Tout dépend si le thread de traitement DOIT attendre que tous aients fini, ou si il PEUT le faire sans que ça dérange.

S'il DOIT attendre, autant ne pas exécuter le thread de traitement. Tu lances tous les autres en les comptant, et tu décrémentes dans le OnTerminate de chaque thread de lecture (nul besoin de synchroniser, le OnTerminate l'est déjà). Dès que tu retombes à 0, hop tu lances le thread de traitement. Concernant les threads de lecture, il faut les synchroniser les écritures puisqu'ils ne font qu'écrire, donc peu importe, tu peux par exemple utiliser une simple section critique protégeant le code partagé.

S'il PEUT attendre, mais qu'il peut aussi traiter dès qu'il y a des données, alors une des façons de faire qui serait intéressante est celle de la file protégée : les lectures arrivent, s'entassent, et sont traités de façon à ce que la première arrivée dans la file soit la première traitée.

C'est ce que tu fais avec les queues de la JVCL par exemple : les threads de lecture ne font qu'une chose : ils font "enqueue" dès qu'une valeur est lue et qu'ils veulent l'enregistrer pour que le thread de traitement s'en occuppe plus tard. Plusieurs threads (11 visiblement) lecteurs font cela, puis se terminent.
Mais au début, le thread de traitement a aussi été lancé, et régulièrement, il regarde s'il y a des valeurs dans la file ; ça ressemble grosso modo à ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
  repeat
    Sleep(500);
    while NOT Queue.Empty do
      begin
        vValeur := Queue.Dequeue; // le dequeue vire la valeur de la liste
        TraiterValeur(vValeur);
      end;
  until Terminated OR YaVraimentPlusRienALire

Normalement, quand on synchronise parfaitement les threads entre eux, on n'a pas besoin d'écrire "Sleep".

Pour ce faire, tu peux utiliser un TEvent, qui fera patienter le thread de traitement, et qui permettra à chaque autre thread de secouer ce dernier pour lui dire "c'est bon ya (au moins) une valeur à lire".

En lecture c'est comme ça:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Event.SetEvent;

Dans le traitement, à la place du précédent Sleep(500), c'est

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Event.WaitFor(5000);

5000 est le TimeOut, tu peux mettre INFINITE mais je te le déconseille ainsi ça ne sortira du WaitFor que si un autre thread le signale explicitement (SetEvent) ou si le TimeOut expire.

Amuse-toi bien

Bon dev'