Добрый день.

Стоит задача организации супер низколатентного взаимодействия между параллельными потоками. Под взаимодействием подразумевается передача данных.

В первом приближении архитектура такова: 1 провайдер - N получателей.

По опыту изучения проблемы уже испробовал и lock-free очереди, и синхронизация по атомик переменным, по conditional переменным, мьютексы, spin-lock и т.д. Но в каждом варианте все равно фиксирую неприемлимые либо задержки в передаче данных, либо серьезное деградировании и конкуренцию ресурсов машины.

Какие требования я перед собой ставлю:
1. максимальное быстрое получение данных подписчиком с момента получения даннх провайдером. счет на микросекунды (>10мкс уже провал)
2. малое потребление ресурсов машины
3. пока windows

Был бы признателен если кто пожелает поделиться опытом, поскольку я в некотором тупике.

Спасибо.

Anatoly Moskovskyaspi,

1) Попробуйте накапливать сообщения в генерирующем потоке и передавать их группами.
Тогда требования к синхронизации снизятся.

2) А вы уверены что задержка именно в синхронизации? Может получатель медленно обрабатывает сообщения и поэтому следующие к нему доходят с задержкой?

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

4) Если активных потоков больше чем ядер, тогда ОС вынуждена переключаться между потоками выделяя им по очереди кванты времени для выполнения на данном ядре. При этом остальные потоки, запланированные для выполнения на том же ядре, усыпляются.
Насколько я помню эти кванты времени достаточно большие, чтото вроде 1 мс (но могу ошибаться).
Это может быть причиной того что сообщения доставляются с задержкой.


Анатолий,
1. Именно так я и делаю. Провайдер получает извне данные, накапливая в буфер. Затем этот буфер нужно отдать получателям.
2. Задержка именно в синхронизации, то есть время с момента получения всех данных провайдером и временем как эти данные получил подписчик.
3. Насколько я понял, Вы предлагаете строго назначать поток-ядро
4. сейчас работающих потоков точно меньше чем ядер.


Bred eFeMaspi,

счет на микросекунды ???
ну а тест на время, без данных и синхронизации Вас устраивает?
(1мкс на 4ГГц = 4000 тактов, а это очень немного даже для RTOS)

может ошибочка, и там миллисекунды, а если нет, то для каких еще задач бережете ресурсы?

Можно покрутить как-то так:
N получателей = X ядер - 1 (провайдер) - 1 (для системы?)
Провайдер-менеджер поддерживает N (получатели между собой не конкурируют) очередей ( без realloc'a )

P.S.
А без потоков, никак? :)


Тест на время в архитектуре провайдер-подписчик без данных не устраивает. Проблема в данном случае не в колве данных, а в способе взимодействия между потоками. То есть если предположить, что один пишет другой читает, например лок-фри очередь, без принужительно ожидания (например слип), то жрется проц время, то в данном случает задержек в получении данных между провайдер-подписчик нет и это устраивает. Но проблема в том, что в таком случае каждый из этих потоков делает дикое колво холостых циклов, грузит процессор и это совсем не профессионально и глупо. Тем более, колво подписчиков в будущем мне надо увеличивать и они должны все быть в равных стартовых позициях относительно получения одного и тогоже куска данных от провайдера.
Без потоков никак.

MasterZiv Тут только надо в рассуждении потоки заменить процессорами, на которых они выполняются. Потому что NUMA относится к ядрам и физическим блокам памяти, а не к логическим потокам управления.
Потоки же в SMP могут кочевать с одного ядра на другое, если не задавать affinity.


Понял.


Попробую резюмировать Задачу:
1. Есть один провайдер-один подписчик.
2. Провайдер получает данные, складывает себе в буфер. Как только получил все данные (он об этом знает), буфер должен отдаться подписчику.
3. Подписчик ждет данные. как только буфер появился, он его должен прочитать и дальше обработать.

Как синхронизировать потоки таким образом, чтобы минимизировать время с момента получение всех данных провайдером и получения этих данных подписчиком.


Спасибо.

Dimitry SibiryakovaspiКак синхронизировать потоки таким образом, чтобы минимизировать время с момента
получение всех данных провайдером и получения этих данных подписчиком.
Для начала покажи как ты это делал с помощью Windows Events.



например вот так

Dimitry Sibiryakovaspi

Эту цифру пробовал увеличить до 1000?


да, пробовал. в чем скрытый смысл?

Dimitry Sibiryakovaspiда, пробовал. в чем скрытый смысл?
Вывод на консоль довольно тормозной процесс. При малой задержке, SetEvent может вызываться
до того, как в потоке закончится вывод и вызовется WaitFor. Таким образом к задержке между
посылкой сигнала и его приёмом добавится время вывода на экран и ты получишь левые числа.


да, но, скорее всего, потерянный ивент будет если я сдедаю Sleep(1) в main.
Проблема пропадание евентов, за чет того, что ктото торомзит, тоже причина того, что я не могу положиться наних ибо моя задача отработать _все_ ивенты, что сгенерировались провайдером последовательно. Провайдер же может отдавать буферы с частотой до микросекунд. Тогдая если интервал у провайдера вдруг для какойто порции увеличится, то это значит, теоретически и даже фактически, мужду провайдером и потребителем будет зависший(ие) необработанные буферы...

vromanovЧтобы уменьшить взаимоблокировки имеет смысл использовать мультиплексор. Т.е. один процесс выбирает данные извне или из очереди и раскладывает по N очередям. N воркеров разгребают каждый свою очередь.
В этом случае работа одного форкера не мешает второму.

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

всем спасибо. буду думать над архитектурой.