Meilleure pratique pour une exécution sans fin / périodique du code en C#

Si vous jetez un oeil à Extensions réactives, il fournit une façon élégante de le faire en utilisant le Modèle observable.

var timer = Observable.Interval(Timespan.FromMilliseconds(100));
timer.Subscribe(tick => OnSomeCondition());

Une bonne chose à propos des observables est la capacité de composer et de combiner d'autres observables à partir de ceux existants, et même d'utiliser des expressions LINQ pour en créer de nouvelles. Par exemple, si vous voulez avoir une seconde minuterie synchronisée avec la première, mais ne déclenchant que toutes les 1 secondes, vous pouvez dire

var seconds = from tick in timer where tick % 10 == 0 select tick;
seconds.Subscribe(tick => OnSomeOtherCondition());

Au fait, Thread.Sleep n'est probablement jamais une bonne idée.

Un problème de base avec Thread.Sleep que les gens ne sont généralement pas conscients, est que la mise en œuvre interne de Thread.Sleep ne pompe pas les messages STA. L'alternative la meilleure et la plus simple, si vous devez attendre un temps donné et ne pouvez pas utiliser un objet de synchronisation du noyau, est de remplacer Thread.Sleep par Thread.Join sur le thread actuel, avec le délai d'attente souhaité. Thread.Join se comportera de la même manière, c'est-à-dire que le thread attendrait le temps voulu, mais en attendant STA les objets seront pompés.

Pourquoi ceci est important (quelques explications détaillées suivent)?

Parfois, sans même que vous le sachiez, l'un de vos threads peut avoir créé un objet STA COM. (Par exemple, cela se produit parfois dans les coulisses lorsque vous utilisez des API Shell). Supposons maintenant qu'un de vos threads ait créé un objet STA COM, et qu'il soit maintenant dans un appel à Thread.Sleep. Si à un moment donné L'objet COM doit être supprimé (ce qui peut arriver à un moment inattendu par le GC), alors le thread Finalizer va essayer d'appeler le distruvtor de l'objet. Cet appel sera marshalled au thread STA de l'objet, qui sera bloqué.

Maintenant, en fait, vous aurez un fil de finalisation bloqué. Dans ces situations, les objets ne peuvent pas être libérés de la mémoire, et de mauvaises choses suivront.

Donc, la ligne du bas: Thread.Sleep = mauvais. Thread.Join=solution de rechange raisonnable.

Le premier exemple que vous montrez est un moyen plutôt inélégant d'implémenter une minuterie périodique. . Net a un certain nombre d'objets de minuterie qui rendent ce genre de chose presque trivial. Regardez dans System.Windows.Forms.Timer, System.Timers.Timer et System.Threading.Timer.

Par exemple, voici comment vous pouvez utiliser un System.Threading.Timer pour remplacer votre premier exemple:

System.Threading.Timer MyTimer = new System.Threading.Timer(CheckCondition, null, 100, 100);

void CheckCondition(object state)
{
    if (SomeCondition())
    {
        OnSomeCondition();
    }
}

CE code appellera CheckCondition toutes les 100 millisecondes (ou à peu près).

Vous ne fournissez pas beaucoup d'informations sur la raison pour laquelle vous faites cela, ou ce que vous essayez d'accomplir, mais si c'est possible, vous pouvez envisager de créer un service windows.

Utilisez un BackgroundWoker pour des mesures de sécurité de thread supplémentaires:

BackgroundWorker bw = new BackgroundWorker();


bw.WorkerSupportsCancellation = true;


bw.WorkerReportsProgress = true;
.
.
.
private void bw_DoWork(object sender, DoWorkEventArgs e)
{
    BackgroundWorker worker = sender as BackgroundWorker;

    for (;;)
    {
        if (worker.CancellationPending == true)
        {
           e.Cancel = true;

           break;
        }

        else
        {
            // Perform a time consuming operation and report progress.

            System.Threading.Thread.Sleep(100);
        }
    }
}

Pour plus d'informations, visitez: http://msdn.microsoft.com/en-us/library/cc221403%28v=vs.95%29.aspx

Un moyen très simple pour attendre non bloquant d'autres threads / tâches est:

(new ManualResetEvent(false)).WaitOne(500); //Waits 500ms