Как реализовать архитектуру многопоточного приложения для отрисовки графика?

Question

[pixik]

Доброго времени, уважаемые разработчики!
Наткнулся на проблему и что-то мне подсказывает, что здесь должен быть некоторый шаблон, потому что проблема довольно типичная.

Суть:
Есть источник данных, который генерит поток со скоростью 5 Гбит/c (USB 3.0).
Проект пишется на С++ с использованием STL, QWT, QT библиотек.
Нужно обрабатывать этот поток в приложении определенным образом (т.е. выполнение некоторой не сильно грузящей математики) или писать на диск поток в виде бинарного файла.

Опыта решения подобных задач у меня нет, по этому решал, как представлял себе.
После недолгих размышлений, я решил сделать так:
Есть 3 потока и расшаренная неблокируемая очередь

1. Поток, принимающий данные с USB и складывающий данные в очередь
   
2. Поток, который в бесконечном цыкле просматривает очередь на наличие объектов. Если очередь имеет объекты,
   то поток дастаёт их из очереди и отправляет на дальнейшую обработку (либо пишет в файл, либо как то обрабатывает и выводит на график)
   
3. Поток GUI, в котором рисуется графика и обрабатываются пользовательское взаимодействие
   

Подскажите пожалуйста, существуют ли типовые приёмы решения подобной задачи? Чем моё решение плохое? Если посоветуете литературу по данному направлению, буду премного благодарен=)
Спасибо всем за участие!

Answer 1

[Владимир Мартьянов]

Ваше решение сходу плохо только тем, что второй поток данные "выводит на график". Дергать гуй из побочного потока - плохая идея, будут странные и плохоуловимые баги с большими шансами. А так все ок, на мой взгляд.

Comments

[pixik]

Я имею в виду дергать гуй с помощью сигналов - слотов, а не на прямую. Все же плохое решение?
Просто хотелось бы изолировать часть гуя от логики.

[Владимир Мартьянов]

pixik: Сигналы-слоты, думаю, не будут таких проблем вызывать.

Answer 2

[DancingOnWater]

Момент номер 1. Qt требует, что гуи жил только в главном потоке. И если математика простая, а скорость по USB не критичная, то пусть математика лежит в том же потоке. что и чтение с USB.

Момент номер 2. Бесконечно крутящийся цикл это последняя мера. В Qt у вас есть сигналы, вот их и пользуйте.
USb принимает данные и толкает сигнал. его подхватывает математика и после обработки толкает сигнал. Его принимает GUI и отображает данные.

Comments

[pixik]

Есть источник данных, который генерит поток со скоростью 5 Гбит/c (USB 3.0).
Скорость критична.

| Qt требует, что гуи жил только в главном потоке.
Об этом моменте я не подумал, но подразумевалось именно это)

| Бесконечно крутящийся цикл это последняя мера
Согласен. Это первое, что пришло в голову. после обдумывания решил сделать ссылку в контейнере (очереди) на поток, который ее просматривает, и при каждом добавлении дёргать поток (если он ещё не обрабатывает коллекцию) на обработку.

[pixik]

или наверно лучше не делать так, чтобы объект содержащий коллекцию значений что то знал о объекте, который его перебирает... Лучше, чтобы объект, перебирающий коллекцию сам каждые ~1мс в бесконечном цикле перебирал коллекцию, если она не нулевая. Как думаете?

[DancingOnWater]

Тогда вам действительно нужен третий поток и кольцевой буфер. Синхронизацию между потоком данных и математикой лучше делать через QWaitCondition,он быстрее STL-вского (личный опыт). Либо брать из boost он еще быстрее.

В нем же можно найти кольцевой буфер.

А вот до Гуи я всеравно предлагаю доставлять данные через сигналы.

[pixik]

| А вот до Гуи я всеравно предлагаю доставлять данные через сигналы.
Так и делаю)

|... и кольцевой буфер
А почему обычная очередь не подойдёт?

| Синхронизацию между потоком данных и математикой лучше делать через QWaitCondition
Почему нельзя все сделать на сигналах / слотах? Синхронизация подразумевает блокировки, а это дополнительные затраты по скорости. Если у меня 1 поток рисует по сигналу, другой проходит коллекцию данных, а третий наполняет коллекцию, то не вижу мест, в которых нужна синхронизация. Подскажите пожалуйста, в каком случае могут быть проблемы и она дейсвтительно будет необходима? У меня опыта в многопоточности нету, и пока не очень очевидно)
Спасибо)

[DancingOnWater]

Блокировки бывают разные и стоимость их тоже разная, но в любом случае принимая данные из внешнего источника в темпе реального времени всегда нужно думать о временных диаграммах и о том, что иногда они нарушаются.
И вот тогда надо чем-то жертвовать: либо вы пропускаете какой-то блок данных, но гарантируете корректность обработки, либо гарантируете прием данных, но не гарантируете корректность его обработки.

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

По сравнению с этим доставка сигнала в очередь на обработку в другой поток на порядок более дорогая операция.