Лучшая практика для бесконечного / периодического выполнения кода в C#

Если вы посмотрите на Реактивные Расширения, он обеспечивает элегантный способ сделать это с помощью наблюдаемые шаблон.

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

хорошая вещь о наблюдаемых-это способность создавать и комбинировать дальнейшие наблюдаемые из существующих и даже использовать выражения LINQ для создания новых. Например, если вы хотите иметь второй таймер, который был синхронизирован с первым, но запускался только каждые 1 секунду, вы можете сказать

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

кстати, Thread.Sleep - вероятно, не хорошая идея.

основная проблема с Thread.Sleep о том, что люди обычно не знают, заключается в том, что внутренняя реализация Thread.Sleep не качает STA сообщения. Лучшая и самая простая альтернатива, если вам нужно подождать определенное время и вы не можете использовать объект синхронизации ядра, - это заменить Thread.Sleep с Thread.Join в текущем потоке с требуемым таймаутом. Thread.Join будет вести себя так же, т. е. поток будет ждать хотел время, но тем временем STA объекты будут прокачиваться.

почему это важно (некоторые подробные explanatiopn образом)?

иногда, даже без вашего ведома, один из ваших потоков, возможно, создал объект STA COM. (Например, это иногда происходит за кулисами, когда вы используете API оболочки). Теперь предположим, что ваш поток создал объект STA COM и теперь находится в вызове Thread.Sleep. Если в какой-то момент COM-объект должен быть удален (что может произойти в непредвиденное время GC), затем поток финализатора попытается вызвать distruvtor объекта. Этот звонок будет упорядоченный объект потока STA, которые будут заблокированы.

теперь, фактически, у вас будет заблокированный поток финализатора. В этих ситуациях объекты не могут быть освобождены от памяти, и за этим последуют плохие вещи.

Итак: Thread.Sleep=плохо. Thread.Join=разумная альтернатива.

первый пример, который вы показываете, является довольно неэлегантным способом реализации периодического таймера. .NET имеет ряд объектов timer, которые делают такие вещи почти тривиальными. Посмотрите в System.Windows.Forms.Timer, System.Timers.Timer и System.Threading.Timer.

например, вот как вы бы использовать System.Threading.Timer для того чтобы заменить ваш первый пример:

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

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

этот код вызовет CheckCondition каждые 100 миллисекунд (или около того).

вы не предоставляете много информации о том, почему вы это делаете, или что вы пытаетесь выполнить, но если это возможно, вы можете изучить создание службы windows.

используйте BackgroundWoker для дополнительных потокобезопасных мер:

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);
        }
    }
}

для получения дополнительной информации посетите: http://msdn.microsoft.com/en-us/library/cc221403%28v=vs.95%29.aspx

очень простой способ не блокировать ожидание других потоков / задач:

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