2012-03-13 2 views
2

J'ai une application WPF avec deux threads de travail d'arrière-plan qui fonctionnent pendant le chargement.Comment puis-je m'assurer qu'un thread de travail d'arrière-plan spécifique s'exécute avant un autre?

Le premier (BW1) est généré au début de l'application, et le second (bw2) est engendré après un certain temps se soit écoulé.

Je suis dans une situation que je ne reproduire le deuxième travailleur de fond (de bw2) de la première de (bw1) « worker_completed ».

Actuellement, j'ai une variable bool de niveau de classe (par défaut false), et mettez-le dans truebw1 « s worker_completed.

Et au départ de bw2, je dois vérifier pour voir si le bool ci-dessus est faux, et si oui, bw2 dormira pendant 100 millisecondes.

Cela fonctionne, pour la plupart. Je voudrais l'améliorer.

  • Puis-je utiliser la priorité de fil dans bw1 (définir comme le plus élevé, par exemple) pour faire en sorte que bw1 est exécutée pendant que BW2 sommeils?

  • Existe-t-il un moyen axé sur les événements que je peux atteindre cet objectif?

+0

Je ne sais pas WPF mais la priorité du travailleur/fil ne doit jamais être utilisé pour la planification des tâches. –

Répondre

4

filature Occupé (même avec le sommeil) est une mauvaise idée quand vous ne savez pas vraiment quand l'événement aura lieu, puisque vous vérifiez aveuglément et en utilisant inutilement les ressources du système. Utilisez à la place un AutoResetEvent. Au début de l'appel ev.WaitOne() code de bw2 et work_completed appel ev.Set() de bw1 à libérer bw2:

AutoResetEvent ev = new AutoResetEvent(); 

// bw1's work completed  
private void bw1_workCompleted(object sender, RunWorkerCompletedEventArgs e) 
{ 
    ev.Set(); // release bw2 from waiting 
} 

// bw2's do work 
private void bw2_DoWork(object sender, DoWorkEventArgs e) 
{ 
    ev.WaitOne(); // wait for the signal from bw1 
    // code 
} 
+0

ev.WaitOne -> ce faisant, pouvons-nous nous assurer qu'il exécutera bw1? – Relativity

+0

@Relativity: lors de l'exécution de 'ev.WaitOne', le thread est retiré de la CPU et n'est plus planifié tant que' ev.Set' n'est pas appelé. Pratiquement, il est suspendu, donc bw1 est libre d'exécuter. – Tudor

Questions connexes