Partager via

Prise en charge du thread dans Bureau

  • Article

Cet article fournit des informations sur la prise en charge du thread dans le modèle objet Microsoft Bureau. Le modèle objet Bureau n’est pas thread-safe, mais il est possible d’utiliser plusieurs threads dans une solution Bureau. application Office lications sont des serveurs COM (Component Object Model). COM permet aux clients d’appeler des serveurs COM sur des threads arbitraires. Pour les serveurs COM qui ne sont pas thread safe, COM fournit un mécanisme permettant de sérialiser des appels simultanés afin qu’un seul thread logique s’exécute sur le serveur à tout moment. Ce mécanisme est appelé modèle STA (Single-Threaded Apartment). Étant donné que les appels sont sérialisés, les appelants peuvent être bloqués pendant des périodes de temps pendant que le serveur est occupé ou gère d’autres appels sur un thread d’arrière-plan.

S’applique à : les informations contenues dans cette rubrique s’appliquent aux projets au niveau du document et aux projets de complément VSTO. Consultez les fonctionnalités disponibles par application Office lication et le type de projet.

Connaissances requises lors de l’utilisation de plusieurs threads

Pour travailler avec plusieurs threads, vous devez avoir au moins une connaissance de base des aspects suivants de la multithreading :

  • API Windows

  • Concepts multithread COM

  • Concurrence

  • Synchronization

  • Marshaling

    Pour obtenir des informations générales sur le multithreading, consultez Threading managé.

    Bureau s’exécute dans la sta principale. Comprendre les implications de cette opération permet de comprendre comment utiliser plusieurs threads avec Bureau.

Scénario de multithreading de base

Le code dans Bureau solutions s’exécute toujours sur le thread d’interface utilisateur principal. Vous souhaiterez peut-être améliorer les performances de l’application en exécutant une tâche distincte sur un thread d’arrière-plan. L’objectif est d’effectuer deux tâches apparemment à la fois au lieu d’une tâche suivie de l’autre, ce qui doit entraîner une exécution plus fluide (la principale raison d’utiliser plusieurs threads). Par exemple, vous pouvez avoir votre code d’événement sur le thread d’interface utilisateur Excel principal, et sur un thread d’arrière-plan, vous pouvez exécuter une tâche qui collecte des données à partir d’un serveur et met à jour les cellules de l’interface utilisateur Excel avec les données du serveur.

Threads d’arrière-plan qui appellent le modèle objet Bureau

Lorsqu’un thread d’arrière-plan effectue un appel à la application Office lication, l’appel est automatiquement marshalé sur la limite STA. Toutefois, il n’existe aucune garantie que la application Office lication peut gérer l’appel au moment où le thread d’arrière-plan le fait. Il existe plusieurs possibilités :

  1. La application Office lication doit pomper les messages pour que l’appel ait la possibilité d’entrer. S’il s’agit d’un traitement lourd sans produire cela peut prendre du temps.

  2. Si un autre thread logique se trouve déjà dans l’appartement, le nouveau thread ne peut pas entrer. Cela se produit souvent lorsqu’un thread logique entre dans la application Office lication, puis effectue un rappel reentrant à l’appartement de l’appelant. L’application est bloquée en attendant que cet appel retourne.

  3. Excel peut être dans un état de sorte qu’il ne peut pas gérer immédiatement un appel entrant. Par exemple, la application Office lication peut afficher une boîte de dialogue modale.

    Pour les possibilités 2 et 3, COM fournit l’interface IMessageFilter . Si le serveur l’implémente, tous les appels entrent via la méthode HandleIncomingCall . Pour la possibilité 2, les appels sont automatiquement rejetés. Pour la possibilité 3, le serveur peut rejeter l’appel, en fonction des circonstances. Si l’appel est rejeté, l’appelant doit décider de ce qu’il faut faire. Normalement, l’appelant implémente IMessageFilter, auquel cas il serait averti du rejet par la méthode RetryRejectCall.

    Toutefois, dans le cas de solutions créées à l’aide des outils de développement Bureau dans Visual Studio, COM Interop convertit tous les appels rejetés en un COMException (« Le filtre de messages indique que l’application est occupée »). Chaque fois que vous effectuez un appel de modèle objet sur un thread d’arrière-plan, vous devez être prêt à gérer cette exception. En règle générale, cela implique une nouvelle tentative pendant un certain temps, puis l’affichage d’une boîte de dialogue. Toutefois, vous pouvez également créer le thread d’arrière-plan en tant que STA, puis inscrire un filtre de message pour ce thread pour gérer ce cas.

Démarrer le thread correctement

Lorsque vous créez un thread STA, définissez l’état de l’appartement sur STA avant de démarrer le thread. L'exemple de code suivant montre comment procéder.

System.Threading.Thread t = new System.Threading.Thread(AnObject.aMethod);

t.SetApartmentState(System.Threading.ApartmentState.STA);
t.Start();

Pour plus d’informations, consultez les meilleures pratiques en matière de threads managés.

Formulaires sans mode

Un formulaire sans mode permet un certain type d’interaction avec l’application pendant l’affichage du formulaire. L’utilisateur interagit avec le formulaire et le formulaire interagit avec l’application sans fermer. Le modèle objet Bureau prend en charge les formulaires sans mode managé. Toutefois, ils ne doivent pas être utilisés sur un thread d’arrière-plan.

Contenu connexe