У меня есть симуляция, написанная на SystemC, которую я хочу запустить как под управлением CLI, так и под управлением GUI (а именно, QT5). Симулятор периодически достигает некоторой точки, которую я хочу отобразить в графическом интерфейсе (на этом этапе я могу приостановить работу симулятора). Симуляция CLI работает отлично, выдает журналы ОК. Я предполагаю, что в QT я могу сначала запустить GUI, а в качестве потока - симуляцию SystemC.
В тот момент, когда в случае CLI ведется запись в журнал, GUI должен быть уведомлен. Затем GUI на некоторое время вступает во владение и запрашивает различные переменные состояния (связь между потоками), отображает их в своем собственном потоке.
Он завершает операцию отображения, затем возобновляет моделирование; и в то же время держит графический интерфейс отзывчивым. Поскольку это только для демонстрации, производительность не критична: пользователь - самый медленный игрок. Я предполагаю, что для этой операции этих двух простых потоков достаточно. Или, может быть, мне понадобится еще один поток, чтобы поддерживать отзывчивость графического интерфейса? Как лучше всего синхронизировать длительную работу графического интерфейса со скоростью симулятора?
Как лучше всего это реализовать, чтобы как можно меньше влиять на источник симулятора (и чтобы избежать зависимости от Qt)? А также таким образом, чтобы как можно меньше влиять на ориентированную на производительность версию CLI?
Это нормально, если я реализую третий поток для связи, который обсуждает детали с потоком симулятора и с GUI или CLI? Какое влияние на производительность оказывает такое решение? (Я имею в виду, что третий поток может взять на себя медленный ввод-вывод для регистрации, и даже он может уравновесить замедляющий эффект связи потока) Есть ли какой-то источник или пример вокруг (то есть не-QT (CLI) или QT (GUI) поток, который уведомлен, затем некоторое время обсуждает с потоком, не относящимся к QT (SystemC), тогда все идет своим путем?