C# Multithreading — Invoquer sans Contrôle

Regarder dans le AsyncOperation classe. Vous créez une instance de AsyncOperation sur le fil que vous voulez l'appeler le gestionnaire sur l'utilisation de la AsyncOperationManager.CreateOperation méthode. L'argument que j'utilise pour Create est généralement nulle, mais vous pouvez la définir à quoi que ce soit. Pour appeler une méthode sur ce thread, utilisez le AsyncOperation.Post méthode.

La méthode de traitement pourrait simplement stocker les données dans une variable membre de la classe. Le seul problème avec la croix-threading se produit lorsque vous souhaitez mettre à jour des threads pour les contrôles qui ne sont pas créés dans le contexte de thread. Donc, votre classe générique pourrait écouter l'événement, puis d'appeler le contrôle que vous souhaitez mettre à jour avec une fonction de délégué.

Encore, seuls les contrôles de l'INTERFACE utilisateur que vous souhaitez mettre à jour doivent être invoquées pour rendre thread-safe. Il y a un moment, j'ai écrit un billet de blog sur un "La Solution la plus Simple pour Illégaux Appels inter-threads en C#"

La poste va plus dans le détail, mais le coeur d'un très simple (mais limité) approche à l'aide d'un anonyme en fonction de délégué sur le contrôle d'INTERFACE utilisateur que vous souhaitez mettre à jour:

if (label1.InvokeRequired) {
  label1.Invoke(
    new ThreadStart(delegate {
      label1.Text = "some text changed from some thread";
    }));
} else {
  label1.Text = "some text changed from the form's thread";
}

J'espère que cette aide. Le InvokeRequired est techniquement facultatif, mais en Invoquant des contrôles est assez coûteux, de sorte que l'enregistrement s'assurer qu'il ne met pas à jour label1.Texte par l'invoquer si ce n'est pas nécessaire.

Si vous êtes en utilisant WPF:

Vous avez besoin d'une référence à l'objet Répartiteur qui gère le thread d'INTERFACE utilisateur. Ensuite, vous pouvez utiliser l'Invoquer ou de la méthode BeginInvoke sur le répartiteur objet pour planifier une opération qui prend place dans le thread de l'INTERFACE utilisateur.

La façon la plus simple pour obtenir le répartiteur est l'aide de l'Application.Actuel.Répartiteur. C'est le régulateur responsable de la principale (et probablement la seule) thread d'INTERFACE utilisateur.

Mettant tous ensemble:

class MyClass
{
    //Can be called on any thread
    public ReceiveLibraryEvent(RoutedEventArgs e)
    {
        if (Application.Current.CheckAccess())
        {
            this.ReceiveLibraryEventInternal(e);
        }
        else
        {
            Application.Current.Dispatcher.Invoke(
                new Action<RoutedEventArgs>(this.ReceiveLibraryEventInternal));
        }
    }

    //Must be called on the UI thread
    private ReceiveLibraryEventInternal(RoutedEventArgs e)
    {
         //Handle event
    }
}

J'ai juste couru dans la même situation. Cependant, dans mon cas, je ne pouvais pas utiliser SynchronizationContext.Courant, parce que je n'ai pas accès aux composants de l'INTERFACE utilisateur et pas de rappel pour capturer l'actuel contexte de synchronisation. Il s'avère que si le code n'est pas en cours d'exécution dans un Windows Forms messge de la pompe, SynchronizationContext.Actuelle est fixée à une norme SynchronizationContext, qui s'exécutera seulement Envoyer des appels sur le thread en cours et après les appels sur le pool de threads.

J'ai trouvé cette réponse expliquant les différents types de synchronisation contextes. Dans mon cas, la solution était de créer une nouvelle WindowsFormsSynchronizationContext objet sur le thread qui seraient par la suite démarrer la pompe de messages à l'aide de l'Application.Run(). Ce contexte de synchronisation peut être utilisée par d'autres threads pour exécuter du code sur le thread de l'INTERFACE utilisateur, sans jamais toucher tous les composants de l'INTERFACE utilisateur.