Коллеги, тема заезженная, но я для себя не нашел подходящего решения.
Задача - наблюдение и управление устройствами по протоколу modbus rtu, подключенными к преобразователям интерфейса USB/RS-485 (не суть важно, к контроллерам). Доступ многопользовательский, для этой цели создан многопоточный сервер, выделяющий для каждого подключившегося клиента свои потоки, в которых осуществляется подключение к устройствам. Запросы выполняются в синхронном режиме - подключение, запрос/ответ, отключение. Асинхронный режим также есть, но это тема для другого разговора, сейчас мне нужно решить другую задачу.

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

Все работает нормально, если конкурируют запросы разных пользователей. Циклы ожидания организуются в разных потоках, очередь движется.
Но если один пользователь начинает делать несколько запросов через малый интервал (например, быстро щелкает мышкой по кнопке), то, из-за медленной реакции устройства (а она может быть от 80 мс до 800), его запросы ставятся в очередь. В программе это можно сделать путем быстрого нажатия несколько раз по кнопке Run. В результате все запросы завершаются таймаутом (Waiting result 0 of request ..).

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

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

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

Это да... Все, спасибо, коллеги, тему можно считать закрытой по причине неправильной постановки задачи

Все так, если запросы в одном потоке, отчего и проблемы.
А если они в разных потоках (от разных клиентов), работает вот это:
т.е. при движении очереди происходит выход из цикла в слоте notificationSlot:

Согласен, но тогда другие сложности. Я сейчас пытаюсь все упростить.

Слишком упрощенно. "Транспорт" - для последовательности запросов к modbus-устройствам? Если да, то в нормальном состоянии длина очереди - 0?
"Устройство" - для хранения текущего состояния устройств? Тогда почему сигнал испускает "Транспорт"?
Заинтересованные объекты по сигналу тупо получают данные из "Устройство"?
Кто выполняет запросы к modbus-устройствам?
Если поясните, будут другие вопросы.

В общем, понятно, хотя смутило "Максимум - 1". Наверное, минимум? А после завершения транзакции, задание должно удаляться, это я имел в виду, говоря про нормальное состояние (точнее - исходное) с длиной очереди 0.

И не совсем понятен транзакционный механизм.

Транзакция завершается, когда получен ответ. С другой стороны, вы говорите, что

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

Ну не знаю, может и нет необходимости обсуждать "всю" архитектуру, что обычно трудно и ничем не кончается. Что если попытаться "сузить" так

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

Если так то почему бы не решить это в главном цикле событий или в созданном (но одном), крутимся там, варианты

- сигнал "очередь обновилась" - проверяем мой (клиента) запрос первый - выполняем действия (посылку, удаление) и возвращаемся в свой EventLoop.

- сигнал "таймаут" (не дождались), и далее по задаче