Работа с двумя потоками в qt

Как я его буду дергать из библиотечной функции вычисления матриц? Мне каждую библиотеку переписывать надо?

Кто мешает организовать обмен данными между потоками через разделяемый объект?

сложная архитектура ЦПУ с кучей кешей. теперь обмен сообщениями - лучшее решение

сложная архитектура ЦПУ с кучей кешей. теперь обмен сообщениями - лучшее решение

один экземпляр std:vector на миллион строк с разными потоками сейчас нельзя использовать? В каждый надо отправлять персональную копию сообщением?

один экземпляр std:vector на миллион строк с разными потоками сейчас нельзя использовать? В каждый надо отправлять персональную копию сообщением?

Отличный способ - рекомендую попробовать.

Да я как сажусь домашку по с++ делать все время думаю про кеши и регистры. Не пропустила я чего? Сложная у меня архитектура ЦПУ или так, фигня для детей?

Мне препопаватель объяснил почему сигналы - это костыли

это бессПОРНО !
ждем преподавателя в треде, пусть нас повеселит, ТС уже не нужен

Там не будет рекурсии. Там только вызов QCoreApplication::processEvents. Внутри него будут обрабатываться слоты. А вот если архитектура через жопу, так это не Qt виноват.

Зачем 20, достаточно 2.

Как же достаточно. Это же разные сущности. :-) Или уже нет? Это называется уперлась за то чтобы «Хочу потоки и все тут…», а тут уже оказывается уже можно по очереди 20 устройств опросить. А перерисовать окно, а потом прочитать данные из порта в одном потоке - так нет, это обязательно нужен поток. Потоки нужно использовать к месту, когда реально упираешься в производительность одного потока, а не когда в голову стукнет.

Легко может случиться. Допустим, у тебя есть метод с долгими вычислениями, который вызывается как от сетевого события, так и от нажатия кнопки. Пришло сообщение из сети, запускаешь вычисления, они вызывают processEvents, а в этом время юзер удачно нажимает кнопку, запускается этот самый метод с вычислениями… Стектрейс будет выглядеть как-то так: event_loop>network_event>super_calculations>event_loop>button_click>super_calculations. Если метод с вычислениями нереентерабельный, то жди сюрпризов, хотя казалось бы нафига ему быть реентерабельным?

А перерисовать окно, а потом прочитать данные из порта в одном потоке

Это принципиальный дефект дизайна и незачет 100%.

Если ты хочешь потренироваться и шишки набить - то ладно. Если нужно проверенное отлаженное рабочее решение - то в Qt уже давно реализован обмен данными между потоками - сигналы/слоты. Нет, ну граждане, это капец какой-то.

Если ты хочешь потренироваться и шишки набить - то ладно. Если нужно проверенное отлаженное рабочее решение - то в Qt уже давно реализован обмен данными между потоками - сигналы/слоты. Нет, ну граждане, это капец какой-то.

Сделать в super_calculations проверку того, что он уже запущен, конечно же нельзя.

И что делать, если он уже запущен? Вхолостую крутиться? Изначальный подход с вызовом processEvents ущербен, Qt Concurrent в помощь.

Это принципиальный дефект дизайна и не зачет 100%.

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

Ок, делай домашку, когда дойдёшь до такого момента как падение производительности при многопоточной обработке - свисти. Пока твои рассуждения на уровне «не читал, но осуждаю». Пробуй, попробуй заполнять вектор из другого потока напрямую, хуже не будет, почитай Таненбаума, задумайся почему в boost появился пакет signals/signals2

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

Зачем? boost мы еще не проходили

Это принципиальный дефект дизайна и не зачет 100%.

Это твои фантазии. Если суммарная сложность действий, производимых одновременно программой такова, что даже на треть не загружается процессор, то разбивка на потоки - это просто инфантильное желание.

А сама?

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

Работа с двумя потоками в qt (комментарий)

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

Не, если тебе всё же действительно нужно проделать эти вычисления.

Вынос тяжёлых вычислений из гуи-потока - это по делу даже при низкой средней загрузке цпу.

Не, если тебе всё же действительно нужно проделать эти вычисления.

Тогда можно проверить, вызвана ли в данный момент нами функция processEvents.

Зачем мне доносить что это правильная архитектура еслия считаю ее неправильной и излишне переусложненной для этого простого случая?

Вот я бы к примеру сделала так:

std::vector<int> v;
std::atomic<bool> busy;

std::thread read_port([&v, &busy] {

тут опрашиваем и читаем датчики в v и пляшем как хотим

когда готово busy = false; и ждем когда его сбросят });

Это все!! Решение простое как 2 пальца.

Вынос тяжёлых вычислений из гуи-потока - это по делу даже при низкой средней загрузке цпу.

Тяжелых - ДА, бесспорно. Но случай чтения из последовательного порта - это тяжелый?

В этой ветке мы обсуждали тяжёлые вычисления и processEvent посреди них.

Зачем мне доносить что это правильная архитектура еслия считаю ее неправильной и излишне переусложненной для этого простого случая?

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

Решение простое как 2 пальца.

меня терзают смутные сомненья ...

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

Это простое но неправильное решение. Оно зависит насколько занят этот поток другими делами.

Когда ты учаcтвуешь в разработке решений уровня продакшен, то лучше когда используются знакомые всем стандартные проверенные решения, а не реализовывается уже существующий функционал. Для прикладника не нужно в каждом проекте с нуля реализовывать такие примитивы, ибо каждый написанный участок кода потребует время на проектирование/тестирование/отладку/исправление/поддержку - это все деньги компании.

По поводу boost - это песочнича, в которой обкатывается все иновационое, что может войти в std, например asio - это часть буста и очень активно используется различными приложениями. Signals - это и есть сигналы и слоты. Насчёт твоего решения - а потом мы организуем цикл проверки состояния и чем это отлино от eventloop qt

Какими делами?

GUI, ты же сам написал, что это все в одном потоке.

Ты точно все читаешь? GUI будет работать и чтение будет работать. Что значит «зависит». - Какой смысл ты в это вкладываешь? Ну перерисуется окно после чтения, и что?

знакомые всем стандартные проверенные решения

Вот чего ты такой упертый :). Еще теперь скажи, что std::thread нестандартный и непроверенный. Почему нас в основном обучают именно std? Может преподаватели не знают что Qt лучше?

Я делал проект, там Qt5.12.0, были чтение/запись из последовательного порта и Gui в одном потоке. В итоге программа работает на одноядерном селероне и за полтора года ни одного зависания или пропущенной посылки не было. А ты мне тут фантазируешь…

Ну перерисуется окно после чтения, и что?

А в окне есть график, а для нового графика надо еще данные посчитать (конечно можно в другом потоке, но ты не разрешаешь). А когда дело до чтения из порта дойдет?

Что я не понимаю в потоках

То что с ними тяжело работать...

Вот чего ты такой упертый

Я имею практической опыт применения.

Еще теперь скажи, что std::thread нестандартный и непроверенный.

Не переиначивай. Если есть Gui на Qt, то вручную реализовывать механизм обмена - это прихоть.

Не решенные...

но ты не разрешаешь

Я не не разрешаю. Я за разумное использование (например очень затратная операция (опять таки с оговоркой про processEvents)).

А когда дело до чтения из порта дойдет?

Сработает сигнал на чтение, вызовется твой слот к этому сигналу - прочитаешь. ВСЕ. Какие проблемы.

Потому что вы нулевые, а препод скорее всего на 4 из 10. В продакшене сидят и работают на 7-8 из 10, по крайней мере на уровне тимлидов и некоторых мидлов, кто мидл только из-за того что тимлидов столько не требуется.

Ладно, я тупая и в продакшене не сижу. Тогда прошу указать недостатки моего решения выше (всего пять строчек) и опровергнуть мое утверждение, что работа с GUI в одном потоке с портом чревато при сложных вычислениях потерей данных.

Какая максимальная задержка t_max на вызов слота по отношению к появлению данных?

Для начала надо задаться вопросом - а оно нам вообще надо?

Я вот тоже хочу тебя спросить, если нечего сказать, то зачем лезть в тему и надувать щеки «В продакшене сидят и работают на 7-8 из 10, ко-ко-ко».

прошу указать недостатки моего решения выше

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

опровергнуть мое утверждение, что работа с GUI в одном потоке с портом чревато при сложных вычислениях потерей данных

Следует оценить скорость порта (очень низкая) и вычислительную мощность процессора (очень высокая) и не выдумывать серийных коней.

Ты должна научиться не давать советов в областях про которые ничего не знаешь и не умеешь.