none
Сильно ли замедлит работу многопоточного приложения использование 10 -15 System.Threading.Timer'ов? RRS feed

  • Вопрос

  • Привет всем.

    Мне нужно контролтровать значение булевой переменной, в классе модели представления, каждые 10 секунд. Текст обработчика таймера примерно следующий:

    void dataAcquisitionTimer_Tick(Object state)
    {
          if (this.IsinId > 0)
          {
                if (!this.F_StartDataAcquisition)
                      this.F_StartDataAcquisition = true;
          }
    }

    Здесь IsinId это Int32, а F_StartDataAcqusition это bool. В приложении, во время работы, будет создано примерно 10 - 15 экземпляров этого класса модели представления и в каждом экземпляре будет работать (тикать) таймер с периодом 10 секунд, с обработчиком, показанным выше. Т.е., в каждом из созданных экземпляров класса модели представления, в обработчике будет контролироваться значение булевой переменной. Это сильно замедлит работу приложения? Всё-таки 10 - 15 тредов будут одновременно крутиться...

    10 сентября 2013 г. 12:32

Ответы

  • Вопрос любопытный.

    Обработчик события (callback) запускается в отдельном потоке, взятом из пула потоков (ThreadPool). Каждый раз поток возвращается в пул (и при следующем тике уже другой поток может быть выделен). Так как ваш колбэк очень быстрый, то это не скажется негативно на производительности.

    Однако, сам Timer потребляет ресурсы. Я поискал точный ответ. Пишут, что можно запускать даже тысячи System.Threading.Timer. Однако, в конечном итоге это может привести к голоданию (starvation) всей системы в целом.

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

    Всё же, 10-15 таймеров - не так уж много. Можно сделать с ними и потестировать приложение. Желательно при активно работающих других тяжёлых приложениях - не скажется ли это на них.

    Ну и наконец, что говорит профайлер? Не ругается?

    • Помечено в качестве ответа TownSparrow 10 сентября 2013 г. 15:30
    10 сентября 2013 г. 13:43

Все ответы

  • Вопрос любопытный.

    Обработчик события (callback) запускается в отдельном потоке, взятом из пула потоков (ThreadPool). Каждый раз поток возвращается в пул (и при следующем тике уже другой поток может быть выделен). Так как ваш колбэк очень быстрый, то это не скажется негативно на производительности.

    Однако, сам Timer потребляет ресурсы. Я поискал точный ответ. Пишут, что можно запускать даже тысячи System.Threading.Timer. Однако, в конечном итоге это может привести к голоданию (starvation) всей системы в целом.

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

    Всё же, 10-15 таймеров - не так уж много. Можно сделать с ними и потестировать приложение. Желательно при активно работающих других тяжёлых приложениях - не скажется ли это на них.

    Ну и наконец, что говорит профайлер? Не ругается?

    • Помечено в качестве ответа TownSparrow 10 сентября 2013 г. 15:30
    10 сентября 2013 г. 13:43
  • Вопрос любопытный.

    . . . . . . . . . . . . . . . . .

    Всё же, 10-15 таймеров - не так уж много. Можно сделать с ними и потестировать приложение. Желательно при активно работающих других тяжёлых приложениях - не скажется ли это на них.

    Ну и наконец, что говорит профайлер? Не ругается?


    Я вот ещё пока не пробовал. Ждал когда ответят. Сейчас вот сделаю ещё кое-что и попробую. Или может уже завтра с утра. В любом случае - спасибо большое за помощь.
    10 сентября 2013 г. 15:29
  • Timers in .Net. В статье сказано, что на любое количество объектов System.Threading.Timer создаётся всего один поток. То есть тот вариант, что я предлагал: коллекция значений и "зажигание" ближайшего, - уже реализован внутри таймера.
    30 сентября 2013 г. 20:14