Timer vs. reetitive background worker

Question

Я разрабатываю приложение Windows Forms, которое вызывает службу WCF по истечении заданного интервала и показывает вывод в соответствии с данными, полученными от службы. У меня был план использовать таймер для этой цели, который вызывает этот метод службы WCF через 500 мс. Но некоторые из моих коллег сказали мне использовать фона рабочего, а затем на Work_Completed событие повторного запуска рабочего. Я хочу знать, в чем разница между этими двумя? Создает ли таймер фоновый поток? Какой из них лучше всего подходит для длительных задач?

Answer 1

A Timer почти наверняка более подходит с точки зрения потребления ресурсов. A BackgroundWorker собирается создать новый поток только для этой задачи. Создание нового потока - довольно дорогостоящая операция.Хотя существует множество различных реализаций таймера, и их реализация будет отличаться, они, как правило, будут полагаться на инструменты ОС, которые будут периодически запускать событие, что будет предпочтительнее запуска нового выделенного потока.

Основные отличия в объектах Timer - это то, что они делают, когда они «готовы». Некоторые создают новый поток пула потоков; некоторые из них имеют выделенный поток, который совместно используется всеми экземплярами таймера для запуска обработчика (-ов), некоторые маршалируют код в поток пользовательского интерфейса (или какой-то другой контекст синхронизации), и это последнее, что вы, вероятно, захотите. Если вы используете таймер, который доступен в определенной структуре пользовательского интерфейса, который вы используете, это поведение, которое вы увидите.

Answer 2

From MSDN website: -

BackgroundWorker создает поток на ThreadPool (через асинхронный делегат Invoke). Таймеры BCL используют либо поток ThreadPool для , либо могут в некоторых случаях поднять события tick/elapsed/etc в потоке пользовательского интерфейса (в случае таймера WinForms или Timers.Timer с ISynchronizeInvoke поставляемый ему).

BackgroundWorker предоставляет оптимальный API для фоновых потоков в среде . Он позволяет использовать метод на фоновом потоке (через событие DoWork) и предоставляет простой способ получить уведомление о прогрессе и завершении в потоке пользовательского интерфейса (ProgressChanged и RunWorkerCOmpleted events), не беспокоясь о каком-либо cross -простой вызов.

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

Threading.Timer - это своего рода таймер «уродливого API». Timers.Timer просто обертывает Threading.Timer в более удобный API и предоставляет способ автоматически вызывать прошедшее событие в потоке пользовательского интерфейса (через свойство SynchronizingObject). Если вы установите свойство SynchronizingObject , код не выполняется в фоновом потоке, он сразу получает , связанный с потоком пользовательского интерфейса.

В общем, внутри пользовательского интерфейса BackgroundWorker проще использовать , чем другие.

Answer 3

Стандарт System.Windows.Forms.Timer должен быть в порядке. Он вызывает обратный вызов в потоке пользовательского интерфейса, что означает, что во время обработки внутри обратного вызова это потенциально заморозит вашу реакцию на интерфейс. Но это только проблема, если вы много работаете внутри обратного вызова или блокируете поток.

Чтобы избежать блокировки потока, просто выполните асинхронный вызов WCF.

A BackgroundWorker не имеет смысла для того, что вы хотите сделать. Все, что вы хотите сделать, это подождать 500 мс, прежде чем выполнять какой-либо код, поэтому просто используйте System.Windows.Forms.Timer.

Answer 4

По моему опыту, основное преимущество Background Worker состоит в том, что события ProgressChanged и RunWorkerCompleted будут выполняться в той же теме, в которой был создан экземпляр рабочего. Итак, если вы запустили фонового рабочего в потоке пользовательского интерфейса, событие RunWorkerCompleted также будет запускаться в потоке пользовательского интерфейса. Это делает так, что вам не нужно беспокоиться о том, чтобы делать незаконные вызовы с перекрестными потоками, если вы хотите обновить компоненты своего пользовательского интерфейса при завершении фоновой работы.