Коллеги, подскажите, пожалуйста, как организуется ожидание данных в асинхронном режиме?
Задача - взаимодействие по типу запрос/ответ с устройством (контроллером) через сокет. Есть функция, которая выполняет передачу запроса в сокет (функция запроса). Чтение ответа от контроллера выполняется асинхронно, по сигналу readyRead (обработчик ответа).
Мне нужно в функции запроса дождаться ответа железяки, прочесть его и отправить куда надо. Т.е. в функции нужно организовать ожидание и фиксацию завершения работы обработчика ответа. Как передать данные - отдельный вопрос, и речь не о нем.

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

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

Собственно, чего темнить - обмен по modbus TCP. Задумка была такая - запросы клиенты передают запросы каждый в своем порожденном процессе. Т.е., подключился к контроллеру, передал, отключился. И ждет некоторое время.
А все ответы получает основной процесс по 502-му порту и складывает в кучку, например, в БД. Вот клиентский процесс должен подождать, когда его ответ появится и забрать.
Возможно, я ошибаюсь - хотел потом проверить. Контроллер можно настроить на любой порт, но сервер всегда должен слушать 502-й. Вот это я и хотел использовать.
Есть, конечно, другое решение - два последовательных запроса (передача запроса, потом получение ответа).

С контроллером (железякой) должен общаться только программный сервер в режиме "Master-Slave", причем мастер - это сервер. Он же по сети принимает запросы от всех клиентов и формирует очередь запросов к контроллеру. После исполнения запроса контроллером происходит анализ ответа и определение клиента, пославшего этот запрос. И только этому клиенту отправляется ответ (или уведомление о таймауте его запроса). Железяка все-равно не будет исполнять запросы параллельно.

Может и нельзя. А я разве задавал вопрос о том, можно ли так сделать? Контроллеры бываю разные...

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

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

Не вижу проблемы. У меня был тупо QEventLoop c таймером в 500 мс. Если за 500 мс не пришёл ответ - следующий запрос, текущее устройство недоступно.