Modèle de gestion des threads d’exécution

Découvrez comment les threads d’exécution, les pools de threads et les règles de répartition influencent l’exécution des NetLogics, le choix des tâches et les performances.

Aperçu

Applications FactoryTalk Optix
 utilise plusieurs modèles d’exécution. Le travail d’exécution ne s’exécute pas sur un thread global unique. L’exécution utilise un pool de threads partagé basé sur les priorités, un pool de temporisateurs et des threads de sous-système dédiés.
Ce modèle détermine la manière dont le code NetLogic s’exécute, dont les rappels sont sérialisés et dont la charge système influe sur le comportement de l’application.

Pools de threads partagés et threads dédiés

Le pool de threads partagé basé sur les priorités exécute le travail d’exécution général. L’exécution planifie le travail en fonction de la priorité et des threads de travail disponibles. Le pool de temporisateurs gère les rappels basés sur des temporisateurs. Certains sous-systèmes utilisent des threads dédiés au lieu des pools partagés.
Des threads dédiés aux sous-systèmes isolent les traitements qui doivent rester réactifs ou s’exécuter dans un ordre déterminé. Les pilotes de communication peuvent utiliser leur propre modèle de gestion des threads, en fonction de la conception du pilote et des besoins du protocole.

Répartition et sérialisation

L’exécution utilise une répartition basée sur l’affinité pour de nombreuses opérations. Le travail qui cible le même objet d’exécution ou le même contexte d’exécution peut être exécuté avec la même affinité et dans un ordre sérialisé. La sérialisation réduit l’accès simultané au même état, mais cela ne signifie pas que tout le travail d’exécution s’exécute sur un seul thread.
Des objets ou sous-systèmes indépendants peuvent s’exécuter en parallèle sur différents threads. Les ressources partagées nécessitent toujours une conception sécurisée pour les threads lorsque le code peut être exécuté à partir de différents contextes.

Modèle d’exécution de NetLogic

Le code NetLogic peut être exécuté dans différents contextes d’exécution.
Start()
 et
Stop()
 suivent les règles du cycle de vie de NetLogic décrites dans Cycle de vie de NetLogic. Les méthodes exportées, les rappels d’événement, les temporisateurs et les tâches asynchrones peuvent être exécutés sur différents threads, en fonction de l’appelant et du planificateur d’exécution.
Ne partez pas du principe que les appels ultérieurs réutilisent le même thread. Concevez le code NetLogic de sorte que l’état partagé soit explicite, limité et protégé lorsque l’accès simultané est possible.

Tâche de longue durée

LongRunningTask
 est l’option privilégiée pour les opérations longues ou bloquantes qui doivent accéder au modèle d’information. Elle sépare les tâches de longue durée de l’exécution du cycle de vie et aide à maintenir la réactivité du comportement d’exécution.
Utilisez
async/await
 ou les API de pool de threads .NET uniquement pour le travail qui n’accède pas aux nœuds du projet. Pour plus de détails sur l’API, consultez Constructeur : LongRunningTask(action, executingNode).

Considérations matérielles

Le débit d’exécution dépend à la fois du nombre de cœurs du processeur et de sa fréquence d’horloge. Un plus grand nombre de cœurs augmente le parallélisme potentiel. Une fréquence d’horloge plus élevée améliore les performances monothread et celles des charges de travail sérialisées.
L’hyper-threading, ou multithreading simultané (SMT), peut améliorer l’utilisation du processeur, mais les cœurs logiques n’égalent pas les performances d’un plus grand nombre de cœurs physiques. Les gains de performances dépendent du type de charge de travail, du comportement de blocage et des conflits d’accès.

Principes de conception

Utilisez ces principes lorsque vous concevez du code NetLogic pour l’exécution :
  • Veillez à ce que les méthodes
    Start()
     et
    Stop()
     restent courtes.
  • Déplacez les tâches bloquantes ou de longue durée vers
    LongRunningTask
     ou un autre type de tâche approprié.
  • Évitez les hypothèses sur l’identité des threads ou l’ordre des rappels entre les sous-systèmes.
  • Protégez l’état mutable partagé.
  • Réduisez les conflits d’accès aux ressources partagées.
  • Effectuez les tests avec des charges réalistes du processeur, des E/S et des communications.
Fournir une réponse
Vous avez des questions ou des commentaires sur cette documentation ? Veuillez envoyer vos commentaires ici.
Normal