Есть некий класс, который имеет событие OnDataReceived. Класс запускает thread, который работает с устройством и по приходу данных должен генерировать это событие.
Данные идут большим потоком, следовательно события должны генерироваться довольно часто, но обработчики этого события могут быть долгими. Как корректно решить эту проблему, чтобы опрос устройства не останавливался?
Вижу 2 варианта:

1) предположить что обработчики событий достаточно быстрые и запускать их как обычно из контекста потока, в котором выполняется опрос устройства. То есть пока все обработчики не отработают, данные с устройства не принимаются — не айс.
2) запускать обработчики событий через ThreadPool.QueueUserWorkItem или Task. сразу возникает вопрос — если второе событие будет запущено когда еще не отработали обработчики первого — необходима синхронизация?

Возможно есть более правильное и элегантное решение?

Здравствуйте, just.slon, Вы писали:

JS>Возможно есть более правильное и элегантное решение?

Если желательно сохранить порядок обработки данных, то используйте два потока и BlockingCollection<T>

Из описания проблемы понятно, что все события с устройства ты обработать не в состоянии. Простая очередь не поможет — она рано или поздно пожрет всю память, да и смысла хранить старые события нет. Нужна обновляемая очередь, хранящая наиболее свежие события по уникальным точкам (сенсорам или что там у тебя).

Здравствуйте, just.slon, Вы писали:


JS>1) предположить что обработчики событий достаточно быстрые и запускать их как обычно из контекста потока, в котором выполняется опрос устройства. То есть пока все обработчики не отработают, данные с устройства не принимаются — не айс.
JS>2) запускать обработчики событий через ThreadPool.QueueUserWorkItem или Task. сразу возникает вопрос — если второе событие будет запущено когда еще не отработали обработчики первого — необходима синхронизация?


Правильно запускать обработчики через ThreadPool.QueueUserWorkItem и позаботиться о том, чтобы не было проблем с синхронизацией. В частности, если у вас данные кладутся в БД — то поднимать новое соединение с БД из каждого обработчика и не закладываться на ограниченное количество соединений

Здравствуйте, just.slon, Вы писали:

JS>Возможно есть более правильное и элегантное решение?
Если скорость обработки данных меньше, чем скорость их поступления, рано или поздно вы упретесь в нехватку памяти, как бы и где бы вы ни организовали очередь для хранения этих данных. Очередь будет иметь смысл, если данные все-таки приходят "пачками", и есть паузы, достаточные для выполнения обработки.

Надо бы уточнить.

Здравствуйте, Sshur, Вы писали:

S>Правильно запускать обработчики через ThreadPool.QueueUserWorkItem
Начиная с 4-го FW и 5-го SL, правильно похоронить с почестями ThreadPool.QueueUserWorkItem и юзать TPL.

Здравствуйте, HowardLovekraft, Вы писали:

HL>Здравствуйте, Sshur, Вы писали:

S>>Правильно запускать обработчики через ThreadPool.QueueUserWorkItem
HL>Начиная с 4-го FW и 5-го SL, правильно похоронить с почестями ThreadPool.QueueUserWorkItem и юзать TPL.


Ну в контексте вопроса был ThreadPool. А так пофиг чем делать, главное чтобы самому не думать о количестве выделенных потоков.