Книги этой я не читал (как впрочем и др. книг) но, судя по Вашей цитате, написано там все правильно. Обычно главная нитка держит UI и контролирует др. нитки (напр может их остановить/прервать). То есть "менеджер", который в основном спит. Если же Вы поручаете ей черновую работу (обработку) - ну то и получаете что рассказали. Нужно перепланировать, соображения такие:

- чего это нитка только получает задания и отфутболивает их главной? Нет ли возможности организовать обработку в той же нитке, а главной только сообщать "столько-то сделано"?

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

- слово "интенсивный" само по себе ни о чем не говорит: частота обмена 10 раз в секунду или в миллисекунду? Если в милли - надо избавляться от сигналов.

Сигналы между нитками сводятся к обмену через eventLoop, а он скоростью не блещет. Заодно надо проверить а действительно ли происходит отсылка в др. нитку (просто здесь легко ошибиться). Ну и конечно, точки должны посылаться "пакетами", слишком жирно вызывать отрисовку для каждой пришедшей. Может быть вообще не заниматься посылкой, а просто рабочая нитка складывает пришедшие точки в контейнер, а главная (с какой-то разумной частотой) их оттуда вынимает. Придется защитить запись/чтение в контейнер но это решает проблемы со скоростью.

Ну если предприятие принимает такой стандарт (немедленно рисовать каждую  точку, не использовать семафоры и мьютексы  и.т.п) - то такое предприятие должно быть готово к возможным последствиям  Лучшее что можно сделать - вынести "обработку" (не знаю в чем она заключается) из главной нитки - но это все.

В главном потоке в бесконечном цикле можно читать точки из любого места. Со всеми семафорами и мьютексами. Чтоб гуй не тормозил можно в конце каждого шага цикла вызывать processEvents. Но это жуткие костыли. И, как мне кажется, если до этого доходит то где-то раньше в логике напартачили. И не важно радиолокация это или нет. Если у вас, как вы писали, рисуется точка раз в 4 мс. То рисуя пачками по, например, 10 вы получите обновление картинки раз в 40 мс, не думаю что человеческий глаз заметит разницу, а кол-во сигналов вы уменьшите прилично.
Временные задержки критичны при работе с железом, для человека это не так важно. Я не знаю сколько человек успевает увидеть, но много работал с речью и радиосвязью. Для речи задержки до 100мс не критичны, человек их просто не замечает. Так что буферизация вполне себе допустима.

Классы QMutex, QReadWriteLock, QSemaphore, QWaitCondition и глава справки про поддержку потоков Qt. Читайте, выбирайте)