Discussion :

[flepron]

Je fais une architecture avec des plugins qui sont des DLL et j'utilise parfois des TThread dans ces DLL qui sont chargé dans une application. Tout le monde, sait que pour qu'un TThread puisse agir sur un contrôle de la VCL, il faut passer par la méthode Synchronize.

Ceci fonctionne à merveille quand le Thread appartient à l'application, mais quand ce Thread a été créé dans la DLL, alors au passage sur la méthode Synchronize, l'application bloque.

Dans la littérature, il est dit que le Thread rend la main au Thread principal de l'application pour lui permettre d'agir sur les contrôles pour éviter les accés concomitant.

Je pense que le code de la DLL n'arive pas à rendre la main au Thread principal de l'application.

Si toute fois, une personne a une idée sur la question, je vous en remercie.

[ZZZzzz2]

Je fais une architecture avec des plugins qui sont des DLL et j'utilise parfois des TThread dans ces DLL qui sont chargé dans une application. Tout le monde, sait que pour qu'un TThread puisse agir sur un contrôle de la VCL, il faut passer par la méthode Synchronize.

Ceci fonctionne à merveille quand le Thread appartient à l'application, mais quand ce Thread a été créé dans la DLL, alors au passage sur la méthode Synchronize, l'application bloque.

Dans la littérature, il est dit que le Thread rend la main au Thread principal de l'application pour lui permettre d'agir sur les contrôles pour éviter les accés concomitant.

Je pense que le code de la DLL n'arive pas à rendre la main au Thread principal de l'application.

Si toute fois, une personne a une idée sur la question, je vous en remercie.

Malheureusement je n'ai pas d'expérience multithread depuis des DLLs mais à priori je ne vois pas en quoi cela changerai quoique ce soit à partir du moment ou ton thread est créé depuis la thread principale d'éxécution (celles qui gère notamment les méthodes VCL et messages windows).
Est-ce bien le cas ? je veux dire, si tu créé une thread depuis une autre thread que la principale alors je ne sais pas si cette nouvelle thread sera capable de faire des appels synchronisés...

Depuis Delphi6 il faut savoir que si ta thread principale utilise l'unité 'Forms' alors les appels à "Synchronize" seront éxécutés dans la thread principale lorsqu'elle rentre dans la boucle de traitement des messages windows et traite le message "OnIdle". Si pour une raison ou une autre ta thread principale ne peut pas entrer dans la boucle de traitement des messages Windows alors ton thread qui appelle "Synchronize" sera bloqué. A moins que tu appelles explicitement "CheckSynchronize" depuis la thread principale.

Toujours est-il que je te conseille de regarder simplement l'aide de Delphi et notamment la méthode "CheckSynchronize" et la variable "WakeMainThread"...

[Reisubar]

Quelle version de Delphi ? J'avais trouvé la solution sur Usenet un jour que je devais avoir le même problème que toi :

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
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
unit DllThread;
 
interface
 
Uses
  Classes, ExtCtrls;
 
Type
  TDLLThread = class(TThread)
  private
    CheckTimer       : TTimer;
 
    procedure DoSynchronizeCheck(Sender : TObject);
  protected
    Procedure DllSynchronize(Method : TThreadMethod);
  Public
    Constructor DllCreate(CreateSuspended: Boolean);
    Destructor Destroy; Override;
  end;
 
implementation
 
{ TDLLThread }
 
constructor TDLLThread.DllCreate(CreateSuspended: Boolean);
begin
  CheckTimer := TTimer.Create(nil);
  CheckTimer.Interval := 1;
  CheckTimer.Enabled := FALSE;
  CheckTimer.OnTimer := DoSynchronizeCheck;
  inherited Create(CreateSuspended);
end;
 
destructor TDLLThread.Destroy;
begin
  CheckTimer.Free;
  inherited;
end;
 
procedure TDLLThread.DllSynchronize(Method: TThreadMethod);
begin
  CheckTimer.Enabled := TRUE;
  Synchronize(Method);
end;
 
procedure TDLLThread.DoSynchronizeCheck(Sender: TObject);
begin
  CheckTimer.Enabled := CheckSynchronize;
end;
 
end.

[flepron]

Je vais essayer cette méthode et je vous remercie de me donner cette piste. Je vous réponds sur le résulat de mes tests.
Merci. François.

[DMO]

Salut,

Voici une explication.
Dans l'unité classes, les méthodes en attente d'être synchronisées par le thread principal sont ajoutés à la liste en variable globale suivante :

Code :

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

SyncList: TList = nil;

De l'autre côté, la liste est vidée régulèrement par le thread principal lorsqu'il appelle CheckSynchronize (ce qui se fait tout seul dans le contexte habituel d'une application).
Tant que le thread principal n'appelle pas CheckSynchronize, le thread appelant Synchronize n'en sort pas et donc en effet "ça bloque"...
L'aide sur CheckSynchronize dit ce qu'il faut faire :

Il n'est pas nécessaire d'appeler CheckSynchronize dans une application d'interface utilisateur graphique (GUI). L'appel à CheckSynchronize est automatiquement effectué par l'objet application. Dans une application non graphique, vous devez appeler CheckSynchronize si vous utilisez la méthode Synchronize de TThread. Pour cela, initialisez la variable WakeMainThread avec une procédure qui appelle CheckSynchronize.

CheckSynchronize permet aux threads d'arrière-plan de synchroniser leur exécution avec le thread principal, afin que les appels de méthodes dans le thread d'arrière-plan soient sécurisés.

CheckSynchronize renvoie la valeur True si une méthode était synchronisée, la valeur False sinon.

Donc faut certainement creuser la piste de WakeMainThread.

Sinon comme ça sans trop réfléchir, si l'application et les DLL sont construites sans les paquets (ou si chacune utilise un gestionnaire de mémoire fesant le même effet), alors peut-être que le fait de partager le même espace mémoire permettra à la DLL de se faire synchroniser par l'application principale puisque c'est la même "SyncList" qui sera utilisée. À étudier.

Bon dev'.

[flepron]

La méthode Reisubar du 11/08/2006 à 13h21 convient parfaitement.

Il suffit donc d'ajouter un timer qui va permettre de au thread principal de débloquer les appels au fonctions Synchronize des threads tiers se trouvant dans des dll.

Merci encore beaucoup.

François Lépron

[Résolu]