Насчет "параллельных", возможно термин выбран не совсем удачно. Но элементы присутствуют.
Имеем COM-объект в котором происходят около 10-ка различных событий с частотой от нескольких в мин до десятков в сек.
Пока работаю с тремя из них.
Мы подписаны на эти события, и по каждому из них получаем некий поток данных, где-то около 10-20 как-то упакованных параметров. Уже понятно, что обработать их в реальном масштабе времени нереально. Поэтому обработчики событий сделаны оч легкими и просто преобразуют данные в объект и укладывают их в стек. Используется коллекция. (Реализовано)

Пока предполагается (нереализовано) , что организуем 3 потока, которые считывают [0] элемент коллекции (если таковой существует), удаляют его из коллекции и далее обрабатывают. Поток события в тоже самое время приостанавливает поток обработчика стека и кладет в коллекцию (стек) следующие элементы. И далее по кругу.
Собственно, мы получаем совместный доступ к изменению данных - 1. добавление элемента, запись 2.чтение, удаление элемента.
Нужна какая-то организация этого процесса, какие-то флаги и обмен ими. Приоритет у обработчика событий. Обработчик стека может и подождать.
Ничего вразумительного о построении таких систем пока не нашел. Ищу.
Если кто знает как это организуется, буду признателен за любую инфу.

"Есть многое на свете, друг Горацио, что и не сразу в голову придет."
М. Твен "Приключения Геккельбери Финна"

bazile, SeVa, Спасибо, буду смотреть.

После прочтения глав Рихтера "CLR via C#", пока предварительно решил не связываться с синхронизацией потоков. Оч уж большие издержки при приостановке потоков, что у него (Рихтера) и написано.
Пока попробую следующее.
Потоку передается объект содержащий коллекцию ListArray, кол-во данных для считывания и флаги состояния потока.
После считывания заданного кол-ва данных поток устанавливает флаг окончания работы с коллекцией.
Основной поток события проверяет флаг, удаляет из начала коллекции уже ненужные считанные данные и передает потоку новое кол-во данных и флаг продолжения задачи.
Далее по кругу.
Один пишет, другой читает. Никакой конкуренции, синхронизации и приостановки потока.
Завтра (уже сегодня) начну делать.
Данных оказалось значительно больше, чем предполагалось. По каждому из событию приходит где-то до 500 параметров.
bazile , отдельное спасибо за книгу.

Где-то в степи, LR Наверно немного не поняли, или я не понял. Событие постоянно кладет на верх ArrayList, поток постоянно читает снизу.
Событие передает потоку текущий размер коллекции, по флагу окончания цикла чтения потоком. И продолжает дополнять коллекцию сверху. Поток читает данные от 0 до переданного размера, выставляет флаг окончания чтения и уходит в бесконечный цикл до следующего получения размера коллекции. Событие по флагу окончания чтения удаляет уже считанные элементы ArrayList и опять передает потоку текущий размер. И по кругу.
Проблема c FIFO (класс Queue) м.б. в возможности одновременного добавлении элемента и удалении первого потоком и необходимости синхронизации этого момента.

А с пулом потоков, да, один из вариантов.

LRГде-то в степи,
совершенно верно, если есть возможность засунуть "каждый чих" в отдельный поток, то так и следует поступать в условиях "в реальном масштабе времени"То, что сейчас делаю, называется - "конвейер". Никакой конкуренции между событием и потоком просто не существует.
Если успевать не будет, буду думать о распараллеливании по потокам. А с пулом м.б. даже сегодня попробую.

ЗЫ СОМ-объект, зараза, по событию выдает мне не обновление, а всю, местами изменившуюся, таблицу параметров. Надо "виртуальную" БД делать, чтобы по insert-update только изменившиеся строки писать. Хотя все равно SQL-сервер цеплять. Вот и еще поток, в фоновом режиме в SQL-сервер инфу толкать. + пользовательские интефейсы, таблицы, алармы, графики, строить.
У National Instrumens есть среда LabView для подобных задач, но она здесь, к сожалению, не прокатывает.

Где-то в степи, HFT пишу, пока модель для отработки. Кроме стакана, сделки + 1 мин ТФ. Не забудь, что это все еще обсчитывать надо.
Люди, вообще-то, спец. платы в компьютер вставляют. Народ на конференции по алготрейдингу говорил, что Винда не успевает, но подробности, ясно дело, никто не говорит.
Судя по уже полученным таблицам, сделок в обычном режиме где-то ~50/c. Вся таблица где-то ~500 строк.

Где-то в степиYUBA,
высокочастотную торговлю, по интернету, хм, жалко ..
как вы себе представляете, с нестабильной плазой, с недостоверными данными ( почитайте редбула), конце концов с простым обманом, когда меркетмейкеры встают просто перед вами, хотя биржа и предлагает размещать высокочастотные роботы у себя на площадке ( напрямую) вызывает сомнение.( в стране где все построено на обмане вдруг появилась честная биржа с честным регулятором, один штраф которого 10 000 рублей за не добросовестные проведение следок, вызывает нервный хохот)
а по теме, как вы это себе представляете, приходит информация с сом, вы всю обработку засовываете в отдельный поток
поток обрабатывает дает сигнал в лонг, а там уже далеко не лонг - уже в это время прострелило 8-10 событий и тренд против вас.
Всю обработку надо делать в контексте события сома, а не разбрасывать по разным потокам.
не хватает мощи, расширяйте железо, подключайте видеокарту
1.Не надо лезть на фьюч РТС, там этих HFT как грязи. И я им не конкурент, по определению. :)
2. Фьючи ГП И Сбер тоже весьма неплохие инструменты, и более спокойные. Даже руками вполне успеваешь пипсовать - минимум 400-500 п за день, это если в струю не попадешь, но оч утомительно, да и время занимает. И, в общем, практически нереально заниматься постоянно. Только в порядке хобби.
3. Конвеерные вычисления всегда были наиболее быстрыми, а удалить низ коллекции и поднять флаг, времени вообще не занимает, по сравнению с управлением потоками. Тот-же Рихтер пишет, что времени на это уходит уйма и рекомендует по возможности разделять доступ - один только запись - другой только чтение. Что и реализовано. А вот если монопоток чего-то не успеет, мы вообще часть событий потеряем. Событий, кстати, около десятка предполагается.