FAQ DelphiConsultez toutes les FAQ

Note : ceci n'est pas un cours de programmation parallèle, mais juste une QR permettant de montrer aux débutants quelques avantages et inconvénients de la programmation multithread.

Sur un système d'exploitation comme Windows, toute application est décrite comme étant un processus. Un processus est autonome, isolé des autres processus (ils n'ont pas de zones mémoire en commun) et peut exécuter à peu près n'importe quel traitement (l'exception notable, mais non unique, étant l'accès type "driver").
Un processus est identifié, sur le système, par un numéro unique appelé PID (Process IDentifier). On accède à un processus via un handle, qui permet notamment de contrôler l'exécution du processus (fermeture, obtention du code de sortie…).
Un processus est également composé d'un ou plusieurs threads : le premier est appelé thread principal, c'est celui qui est lancé par le système d'exploitation lui-même. Les autres threads seront lancés par un (ou plusieurs) threads du processus.

Mais qu'est-ce qu'un thread ? C'est une unité d'exécution autonome, un "programme dans le programme". Un thread n'existe pas en dehors d'un processus hôte. Un thread est quasiment identique à un processus, à un détail près : les threads ne sont pas isolés, ils partagent le même espace mémoire, celui du processus hôte. Il est important de comprendre qu'un processus n'est, en fait, qu'une "structure de contrôle" : il n'est rien sans son thread principal, qui est le véritable élément exécutable d'un processus.
Bon, mais quel intérêt d'avoir des threads, alors ? Tout simplement que sur certaines opérations "longues", une application (son thread principal, en fait) est bloquée en attente d'une réponse. Le cas le plus connu est l'accès au disque dur, mais c'est en fait le cas de toutes les requêtes vers le système d'exploitation. Une application multithread, elle, peut mettre à profit ce "temps mort" pour exécuter d'autres tâches en attendant la réponse. C'est le système d'exploitation lui-même qui effectue cette détection et la commutation vers d'autres threads (le "passage de main"). Les communications réseau (surtout TCP/IP) profitent par exemple beaucoup du multithreading : pendant qu'un thread secondaire (dit "de communication") s'occupe des transactions sur les sockets, le thread principal peut toujours continuer de s'exécuter.
Sur une application Delphi, ceci permet par exemple de continuer à rafraîchir la fiche principale, de réagir aux actions utilisateur, etc. Un thread peut changer de priorité d'exécution, être suspendu, relancé, etc. Un thread existe même s'il est terminé : ceci notamment pour pouvoir récupérer son code de sortie depuis des threads actifs. Pour définitivement détruire un thread, il faut soit terminer son processus hôte, soit le détruire explicitement. Cependant, un thread terminé ne fait qu'occuper un peu de mémoire, il n'interfère plus dans le séquencement des threads réalisé par le système d'exploitation.
Le principal problème avec les threads, c'est la notion d'accès concurrent, de synchronisation et de réentrance. En effet, le développeur ne peut pas déterminer quand le système d'exploitation va stopper le thread courant pour en exécuter un autre, ni quand le contrôle d'exécution lui reviendra de nouveau.

Accès concurrent :
L'accès concurrent, c'est lorsque deux threads tentent d'accéder à la même donnée "en même temps". En général, ce n'est jamais réellement en même temps, sauf sur un système multiprocesseur. C'est plutôt qu'un thread A accédant à une ressource R a été interrompu, pendant cet accès, par un thread B utilisant lui aussi la même ressource R.
Dans certains cas, ceci n'a aucune importance : par exemple, pour la lecture d'une variable globale. Mais la plupart du temps, c'est critique : par exemple, si deux threads tentent d'incrémenter une variable donnée… Qui va "gagner" ? C'est impossible à déterminer sans mécanismes de synchronisation.

Synchronisation :
Le système d'exploitation fournit ce que l'on appelle des mécanismes de synchronisation pour permettre à deux threads concurrents de ne pas s'interrompre mutuellement. Ainsi, deux threads synchronisés ne peuvent pas se gêner mutuellement. Il existe plusieurs niveaux de synchronisation : soit uniquement entre les threads d'un même processus (synchronisation inter-threads), soit entre les processus du système (synchronisation inter-processus). Bien sûr, tout élément de synchronisation inter-processus peut également être utilisé pour une synchronisation inter-threads, mais c'est en général plus lourd et plus lent que les mécanismes locaux.
Les plus utilisés sont les sections critiques (inter-threads), les mutex (inter-processus), les évènements (inter-processus) et les messages (inter-processus).
Éléments de synchronisation VCL : Unités "SyncObjs.pas" et "SysUtils.pas".
Éléments de synchronisation Win32 : Liens MSDN : Using Critical Section Objects, fonction CreateMutex, fonction CreateEvent, fonction SendMessage.

Réentrance :
La réentrance, c'est le fait qu'une fonction puisse être interrompue par elle-même. Typiquement, toutes les fonctions natives de la VCL (pas vos gestionnaires d'évènements, par exemple, mais des fonctions comme Format) et de l'API Win32 sont réentrantes, c'est à dire qu'il est possible d'appeler la même fonction au sein de plusieurs threads (voire processus) sans ajouter de protection particulière.

Certaines fonctions de la VCL (comme MessageDlg) ne doivent être appelées que depuis le thread principal de l'application. Le problème n'est pas lié à la réentrance de la fonction, mais à son contexte d'exécution.

Toute fonction qui n'utilise que ses paramètres et des variables locales est forcément réentrante : donc, une fonction de calcul "pur" est réentrante. Par contre, toute fonction utilisant une ressource globale directement (variable globale, instance de fiche…) n'est plus réentrante, et devra donc être protégée par un mécanisme de synchronisation. On parle également de ressource critique. Toute la fonction n'est pas à protéger, cependant : seules les lignes de code utilisant la ressource critique doivent être encadrées par une synchronisation.
Exemple de fonction réentrante :

1
2
3
4
Function Reentrant ( Const A, B : Extended ) : Extended ; 
Begin 
     Result:=A*B; 
End;

1
2
3
4
5
6
7
8
Var 
   GlobalVariable : Integer ; 
  
Procedure NonReentrant ( Const Value : Integer ) ; 
Begin 
     If (GlobalVariable>0) Then GlobalVariable:=Value 
                           Else GlobalVariable:=GlobalVariable-1; 
End;

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
Var 
   GlobalVariable : Integer ; 
   GlobalVariableCriticalSection : TCriticalSection ; 
  
Procedure ForcedReentrant ( Const Value : Integer ) ; 
Begin 
     GlobalVariableCriticalSection.Enter; 
     // A partir de ce moment, AUCUN thread utilisant cette section critique ne peut interrompre 
     // l'exécution. Ceci inclut bien entendu la fonction ForcedReentrant elle-même. 
     If (GlobalVariable>0) Then GlobalVariable:=Value 
                           Else GlobalVariable:=GlobalVariable-1; 
     GlobalVariableCriticalSection.Leave; 
     // La section critique est terminée, et les autres threads l'utilisant peuvent désormais 
     // interrompre l'exécution. Cependant, c'est désormais sans risques, l'accès à la variable 
     // globale est terminé. 
End;

• Le thread A verrouille une section critique CS1.
• Le thread B verrouille une section critique CS2.
• Au sein du thread A, on demande à verrouiller CS1 : le thread est bloqué, car le thread B la possède déjà.
• Au sein du thread B, on demande à verrouiller CS2 : le thread est bloqué, car le thread A la possède déjà.
• Aucun des deux threads ne peut continuer à s'exécuter : or, pour débloquer la situation, un des deux doit libérer sa propre CS, ce qui est impossible. Les threads sont interbloqués.
  

Note : ceci n'est pas un cours de programmation parallèle, mais juste une QR permettant de montrer aux débutants les prémices de l'utilisation des threads avec la VCL.
Créer un thread sous Delphi se fait en ajoutant un objet dérivé de TThread à l'application.
Cette classe est déclarée dans l'unité "Classes.pas". Cependant, contrairement aux contrôles classiques (comme par exemple TTimer, TButton…), cette classe ne sait presque rien faire nativement : il faut la surcharger pour définir ce qu'elle fera au sein du programme.

Ajout d'un nouveau thread : Sur un projet ouvert, faites "Fichier", "Nouveau", "Autres" et choisissez "Objet Thread" (sur l'onglet "Nouveau"). L'assistant de Delphi va alors proposer une boîte de dialogue, permettant de nommer le nouveau type de thread. Appelons-le "TTestThread" pour l'exemple. Ne cochez pas la case créant un thread nommé.
Delphi va alors créer une nouvelle unité, déclarant le nouveau thread. Le code ajouté est celui-ci :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
unit Unit1; 
  
interface 
  
uses Classes; 
  
type 
  TTestThread = class(TThread) 
  private 
    { Déclarations privées } 
  protected 
    procedure Execute; override; 
  end; 
  
implementation 
  
{ TTestThread } 
  
procedure TTestThread.Execute; 
begin 
  { Placez le code du thread ici } 
end; 
  
end.

1
2
3
4
5
6
7
procedure TTestThread.Execute; 
begin 
     While Not Terminated Do 
           Begin 
           { Placez le code du thread ici } 
           End; 
end;

1
2
3
4
procedure TTestThread.UpdateForm; 
begin 
     Application.MainForm.Title:=Format("Progression : %d %%",[CurrentPercentDone]); 
end;

1
2
3
4
5
6
Var 
   MyThread : TTestThread ;   // A déclarer de préférence en attribut d'une fiche. 
Begin 
     MyThread:=TTestThread.Create(False); 
     // Le thread est désormais créé, et actif. 
End;

1
2
3
4
// On demande au thread de s'arrêter "proprement". 
MyThread.Terminate; 
// Maintenant, on attend sa fermeture réelle. 
ExitCode:=MyThread.WaitFor;

1
2
3
4
MyThread:=TTestThread.Create(True);   // Thread créé en état "Suspendu". 
MyThread.FreeOnTerminate:=True;       // Libération automatique de l'objet lorsque le thread se termine. 
MyThread.Priority:=tpHighest;         // Thread de haute priorité. 
MyThread.Resume;                      // Thread relancé, et actif.

Note : ceci n'est pas un cours de programmation parallèle, mais juste une QR permettant de montrer aux débutants les prémices de l'utilisation des threads avec l'API Win32.
Créer un thread en utilisant l'API Win32 se fait bien entendu en utilisant des fonctions dédiées, notamment CreateThread. Avec l'API Win32, toute fonction respectant un certain prototype peut devenir un thread. Ce prototype est déclaré via le type TFNThreadStartRoutine, défini comme suit :

1
2
Function TFNThreadStartRoutine ( lpParameter : Pointer ) :  
LongWord ; stdcall ;

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
Function MyThreadProc ( lpParam : Pointer ) : LongWord ; stdcall ; 
Var 
   MyRealParam : PByteArray ; 
Begin 
     // À ce moment, on peut utiliser un transtypage pour récupérer le contenu "réel" 
     // du paramètre lpParam : ça peut être une adresse de tableau, l'adresse d'un Record, 
     // une instance d'un objet particulier, etc... 
     MyRealParam:=PByteArray(lpParam); 
     // Code du thread... 
     .... 
  
     // Utiliser UNE des versions suivantes pour terminer le thread. 
     // ERROR_SUCCESS vaut zéro, c'est le code de retour "OK" par  
convention. 
  
     // Sortie du thread (avec code de retour, version 1) 
     ExitThread(ERROR_SUCCESS) ;   // On sort immédiatement de la fonction,  
comme avec Exit. 
     // Sortie du thread (avec code de retour, version 2) 
     Result:=ERROR_SUCCESS ;       // Le code de retour est positionné, mais  
le thread reste actif. 
     Exit ;                        // Sortie réelle. 
     // Sortie du thread (sans code de retour) 
     Exit; 
End; 
  
Var 
     DataBlock : TByteArray ;  // Paramètre du thread. 
     ThreadID  : DWORD      ;  // Thread ID du nouveau thread. 
     hThread   : HANDLE     ;  // Handle sur le nouveau thread. 
  
Begin 
     // Les deux paramètres principaux sont le 3ème (adresse de la fonction)  
et 4ème (paramètres de la fonction). 
     // Le dernier sert à récupérer le ThreadID du nouveau thread. 
     hThread:=CreateThread(Nil,Nil,@MyThreadProc,@TByteArray,0,ThreadID); 
     If (hThread=0) Then 
        Raise Exception.Create('Impossible de créer le thread.'); 
     // Désormais, les variables hThread et ThreadID sont valides. 
     // Il ne faut JAMAIS "perdre" ces variables, sinon le thread risque de  
devenir 
     // totalement innaccessible, voire incontrôlable. 
End.

• Le ThreadID est valide et utilisable dans tous les threads du processus, et pour les autres processus du système. Il est unique sur l'ensemble du système d'exploitation.
• Le handle retourné est local au thread ayant appelé CreateThread. Pour créer un nouveau handle sur le thread dans un autre thread, il sera nécessaire d'appeler la fonction OpenThread, qui prend le ThreadID en paramètre. Il est possible d'avoir autant de handles que l'on veut sur un même thread, et ils seront tous différents.
  

• Le ThreadID ne sert qu'à retrouver le thread au sein du système d'exploitation, ou pour envoyer des messages à un thread donné.
• Un handle sert dans tous les autres cas : changement de priorité, suspension, reprise, terminaison brutale, attente de la fin du thread, etc.
  

1
2
3
4
5
6
7
8
9
10
11
12
13
14
Var 
   hThread  : HANDLE ; 
   ThreadID : DWORD  ; 
Begin 
     // Création du thread, sur la procédure MyThreadProc. 
     hThread:=CreateThread(Nil,Nil,@MyThreadProc,@MyThreadParam,0,ThreadID); 
     If (hThread=0) Then 
        Raise Exception.Create('Impossible de créer le thread.'); 
     // Changement de priorité : priorité basse. 
     SetThreadPriority(hThread,THREAD_PRIORITY_LOWEST); 
     // Fermeture du handle : on va simplement attendre que le thread se  
termine tout seul. 
     CloseHandle(hThread); 
End.

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
Type 
    PThreadParam = ^TThreadParam ; 
    TThreadParam = Record 
       IntParam  : Integer  ; 
       RealParam : Extended ; 
       StrParam  : PChar    ; 
       End                  ; 
  
// On déclare la procédure de thread directement avec un PThreadParam, pour  
plus de facilité. 
Function MyThreadProc ( Param : PThreadParam ) : LongWord ; stdcall ; 
Begin 
     If (Param^.IntParam>0) Then 
        ... 
     .... 
End; 
  
Var 
   // La variable utilisée en paramètre est globale. 
   ThreadParam : TThreadParam ; 
  
Procedure RunThread ; 
Begin 
     With ThreadParam Do 
          Begin 
          IntParam:=546123; 
          RealParam:=3.14159; 
          StrParam:=PChar('Chaîne en paramètre'); 
          End; 
     CloseHandle(CreateThread(Nil,Nil,@MyThreadProc,@ThreadParam,0,Nil)); 
End;

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
Function MyThreadProc ( Param :  
PThreadParam ) : LongWord ; stdcall ; 
Var 
   MyPrivateParam : TThreadParam ;   // Copie locale au thread des  
paramètres. 
Begin 
     // Recopie des paramètres, puis libération de la mémoire. 
     CopyMemory(@MyPrivateParam,Param,Sizeof(MyPrivateParam)); 
     LocalFree(Param); 
     // Désormais, il est inutile de se préoccuper de libérer la mémoire :  
     // même en cas de crash, il n'y aura pas de fuite mémoire. 
     // Traitement normal, les paramètres sont sécurisés désormais. 
     If (MyPrivateParam.IntParam>0) Then 
        ... 
     .... 
End; 
  
Procedure RunThread ; 
Var 
   ThreadParam : PThreadParam ;   // La variable utilisée est un pointeur  
local. 
Begin 
     // On alloue, via l'API Win32, une zone pour les paramètres du thread. 
     ThreadParam:=PThreadParam(LocalAlloc(LPTR,sizeof(TThreadParam))); 
     With ThreadParam^ Do 
          Begin 
          IntParam:=546123; 
          RealParam:=3.14159; 
          StrParam:=PChar('Chaîne en paramètre'); 
          End; 
     // On crée le thread, c'est lui qui libèrera la mémoire. 
     CloseHandle(CreateThread(Nil,Nil,@MyThreadProc,ThreadParam,0,Nil)); 
End;