Discussion :

[rvzip64]

Salut a tous

Je me suis lancer dans la programmation avec les threads, et je bloque un peu sur la communication entre deux threads.

Je vous explique:

J'ai un thread qui tourne et qui gere un port série et de temps en temps il incremente une variable.
J'ai un autre thread qui lui doit récupérer la valeur de la variable du premier thread, faire un traitement et l afficher dans un TCHAT. Bien entendu il ne doit pas arreter l'autre thread.

Comment dois je faire ??
Je dois utiliser un mutex ??

J'ai lu le cours de Laurent Berne (excellent cours) qui n'utilise pas de méthode de synchronise pour accéder a des composant de la vcl hors du thread.

Je me perd un peu dans tout cela.

Merci d avance

[octal]

le meilleur moyen de communication entre deux thread est de passer par les section critique et les threadvars

[rvzip64]

et tu fais comment tu as un exemple ?

[rvzip64]

Personne ne sait comment il faure fair e?

[sjrd]

Utilisation des sections critiques :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
type
  TThread1 = class
  private
    FCounter : integer;
    FCounterCriticalSection;
    function GetCounter : integer;
    procedure IncCounter;
  public
    property Counter : integer read GetCounter;
  end;
 
implementation
 
function TThread1.GetCounter : integer;
begin
  FCounterCriticalSection.Acquire;
  try
    Result := FCounter;
  finally
    FCounterCriticalSection.Leave;
  end;
end;
 
procedure TThread1.IncCounter;
begin
  FCounterCriticalSection.Acquire;
  try
    inc(FCounter);
  finally
    FCounterCriticalSection.Leave;
  end;
end;

N'oublie pas de créer FCounterCriticalSection dans le constructeur et de le libérer dans le destructeur.

Et n'oublie pas non plus le bouton

[edam]

salut
voir: http://www.phidels.com/php/index.php3?page=../php/pagetelechargementzip.php3&id=336
c'est un bon example pour les section critique

une question: votre 2éme thréade utilise la valeur aprés incrémentation ou a des intevals ou quand?

[rvzip64]

aprés incrementation

[Mac LAK]

J'ai un thread qui tourne et qui gere un port série et de temps en temps il incremente une variable.
J'ai un autre thread qui lui doit récupérer la valeur de la variable du premier thread, faire un traitement et l afficher dans un TCHAT. Bien entendu il ne doit pas arreter l'autre thread.

Vous êtes tous des grosses brutes !!! ;-)

Plus sérieusement, c'est vrai que les sections critiques sont de rigueur lorsque les données à manipuler sont complexes et/ou d'assez grande taille.

Mais pour une synchro aussi simple que celle-là, l'API Win32 te fournit déjà des fonctions atomiques !
Celle que tu vas utiliser à priori sera InterlockedIncrement pour ton incrémentation.
Pour la "lecture", tu utilisera InterlockedCompareExchange avec une valeur à zéro pour la valeur échangée.
Ainsi, ton thread 1 incrémente sa variable tranquillement, et le thread 2 va lui "piquer" cette variable et la remettre à zéro au passage.
Si tu dois conserver la somme totale, c'est dans le thread 2 qu'il faut la conserver.

Ces fonctions existent aussi en Delphi, bien sûr, il me semble qu'elles sont dans l'unité Windows.

[sjrd]

Whaou ! Où t'as été pêcher ça ?

[Mac LAK]

Whaou ! Où t'as été pêcher ça ?

Bon, une perche pareille, je ne peux pas la refuser : j'en dormirai pas pendant des semaines et je suis déjà insomniaque...

;-)

Plus sérieusement, j'ai pas mal épluché l'aide "Win32 Reference", fournie avec Delphi (menu Help | Windows SDK), pour des éléments comme le ShellExecute ou GetIpAddrTable, etc, etc... En plus, j'ai aussi à bosser sur eMbedded Visual C++, et là, c'est "API-only".

A force, tu te rends très vite compte que non seulement tous les types Windows "C" sont définis dans Delphi, mais la plupart des fonctions aussi (les exceptions comme GetIpAddrTable sont rares, et concernent presque toutes le Platform SDK).
Donc, quand j'ai un problème que la VCL ne peut (apparemment) pas résoudre, j'ai pris l'habitude de faire cette démarche :
- Chercher sur MSDN les fonctions Win32 correspondantes,
- Chercher dans les sources de la VCL les appels à ces fonctions,
- Regarder dans quelles fonctions/classes VCL c'est fait.

C'est comme ça, par exemple, que j'ai "découvert" la classe TMultiReadExclusiveWriteSynchronizer (TMREWSync en abrégé), qui est sinon relativement difficile à trouver "comme ça".
Ou encore qu'il est plus pratique d'utiliser les sections critiques de l'OS (RTL_CRITICAL_SECTION) car ce sont des enregistrement, possédant un champ... LockCount ! Or, par défaut, on ne peut pas connaître l'état (pris ou libre) d'un TCriticalSection (gênant).
L'API Win32 fournit une fonction nommée TryEnterCriticalSection, qui permet de pallier ce problème.
Bref, que du bonheur ! ;-)

[edam]

salut
alors pourqoi pas fait ton trétement dans l'evenemnt meme du port série comme sa tu utilisera un seul tréad
tu as pas deux traitement vraiment séparé la 2éme est lier par la premiére :c'est une idée c'est tt

[rvzip64]

donc ca veut dire que si maintenant je veux partager un tableau de valeur entre les deux threads je dois faire comment ?

Les sections critique ne me plaisent pas trop, en effet, ça arrete les autres thread du processus et je ne peux pas me le permettre, vu que le programme est "temps reel" et j ai donc de nombreuse contrainte.

[Mac LAK]

donc ca veut dire que si maintenant je veux partager un tableau de valeur entre les deux threads je dois faire comment ?

Tu peux par exemple utiliser les Interlocks sur les éléments du tableau. Attention à ne pas confondre, cependant : les Interlocks servent à échanger une variable (max : 32 bits) entre des threads, pas des tableaux ou des enregistrements. Tu peux par contre les utiliser sur des membres d'enregistrement ou des éléments de tableau, à condition bien sûr qu'il ne soit pas nécessaire de faire plusieurs opérations simultanément pour maintenir le tableau/enregistrement cohérent.

Les sections critique ne me plaisent pas trop, en effet, ça arrete les autres thread du processus et je ne peux pas me le permettre, vu que le programme est "temps reel" et j ai donc de nombreuse contrainte.

Faux : les CS (ou mutex) ne bloquent que les threads qui les utilisent, et uniquement s'ils entrent en concurrence. Souvent, ça arrive au lancement des threads, puis ils se "régulent" plus ou moins et entrent de moins en moins souvent en concurrence si tu as correctement conçu ton algo.

Un Interlock fait la même chose qu'un mutex, simplement c'est sur une opération tellement courte que ça ne se voit pas, c'est tout.
Comme je l'ai mentionné un peu plus haut, tu peux aussi utiliser une synchro Lecteurs/Rédacteur si tu fait plus souvent de la lecture que de l'écriture. Si les deux opérations sont équiprobables, une CS ou un mutex sont requis.

Différence : une CS est locale à un processus, et est plus rapide à prendre qu'un mutex. Le mutex, par contre, est global au système et peut donc être partagé entre deux processus distincts.
Si les données à échanger de manière atomique sont plus grandes que 32 bits, un système de synchro par CS ou mutex est impératif.

Je fais du temps réel tous les jours, et j'utilise pourtant un paquet de systèmes de synchro : ça n'est pas incompatible (tu confonds "temps réel" et "temps critique").

Ta solution est donc :
- Les valeurs du tableau sont totalement indépendantes les unes des autres et ne sont rangées dans un tableau que par commodité : utilise un Interlock sur les éléments du tableau.
- Le tableau est une entité à part entière, les valeurs contenues doivent évoluer simultanément : la CS est de rigueur.
- Le tableau est une "file" d'évènements consignés, cette file devant être "purgée" vers un autre thread : utiliser un Interlock sur le pointeur pour échanger les buffers.

Ca répond à tes questions ?

[rvzip64]

oui la je crois que cela repond a toute mes questions, c est trés clair, je te remercie.