Delphi Filetage - Quelles parties du code doivent être protégées / synchronisées?

Vous demandez des réponses spécifiques à une question très générale.

En gros, à l'exception des opérations d'interface utilisateur, vous devez protéger chaque accès de mémoire / ressources partagée pour éviter deux threads potentiellement concurrents à: p>

• Lire la mémoire incohérente li>
• écriture de la mémoire en même temps li>
• Essayez d'utiliser la même ressource en même temps à partir de plusieurs threads ... jusqu'à ce que la ressource soit en sécurité. LI> ul>

  En règle générale, je considère toute autre opération de fil d'opération, y compris les opérations qui n'accèdent pas à la mémoire partagée ou non d'objets partagés. P>

  Par exemple, considérez cet objet: P>

  type
    TThrdExample = class
    private
      FValue: Integer;
    public
      procedure Inc;
      procedure Dec;
      function Value: Integer;
      procedure ThreadInc;
      procedure ThreadDec;
      function ThreadValue: Integer;
    end;
  
  ThreadVar
    ThreadValue: Integer;
  

Vous avez mal compris Tthread.Synchroniser la méthode.

TTHead.Synchroniser et TTHead.Queue Méthodes exécute du code protégé dans le contexte du fil principal (GUI). C'est pourquoi vous devez utiliser Syncronize ou la file d'attente pour mettre à jour des contrôles de l'interface graphique (comme ProgressBarbar) - Normalement, seul le thread principal doit accéder aux contrôles de l'interface graphique.

Les sections critiques sont différentes - le code protégé est exécuté dans le contexte du fil qui a acquis une section critique, et aucun autre thread n'est autorisé à acquérir la section critique jusqu'à ce que l'ancien fil le libère.

Vous utilisez une section critique en cas de besoin d'un certain ensemble d'objets à mettre à jour atomiquement. Cela signifie, ils doivent à tout moment être déjà mis à jour complètement ou pas encore mis à jour du tout. Ils ne doivent jamais être accessibles dans un état de transition.

Par exemple, avec une simple lecture / écriture entier, ce n'est pas le cas. Le fonctionnement de la lecture entier ainsi que le fonctionnement de l'écriture Il est déjà atomique: vous ne pouvez pas lire entier au milieu du processeur l'écrivant, à moitié mis à jour. C'est une valeur ancienne ou une nouvelle valeur, toujours.

Mais si vous voulez incrément l'entier atomique, vous n'en avez pas une, mais trois opérations que vous devez faire à la fois: lisez l'ancienne valeur dans le cache du processeur, incrémentez-la et écrivez-le à la mémoire. Chaque opération est atomique, mais les trois d'entre elles ne sont pas.

Un thread peut lire l'ancienne valeur (dire, 200), l'incrémentez-la par 5 dans le cache, et en même temps qu'un autre thread pourrait également lire la valeur (toujours 200). Ensuite, le premier thread écrit 205, tandis que le deuxième fil augmente sa valeur mise en cache de 200 à 203 et écrit 203, écrasement 205. Le résultat de deux incréments (+5 et +3) devrait être de 208, mais il est 203 en raison de -atomicité des opérations.

Ainsi, vous utilisez des sections critiques lorsque:

1. une variable, un ensemble de variables ou une ressource est utilisée à partir de plusieurs threads et doit être mis à jour atomiquement.
2. Ce n'est pas atomique par lui-même (par exemple, appeler une fonction surveillée par une section critique à l'intérieur du corps de la fonction, est déjà une opération atomique)