Russian Qt Forum

CPU x86 800 Мгц. ОС - xlinux. Qt embedded 4.5.3.
Есть необходимость общаться с внешними устройствами через интервалы порядка 1 мс.
Данные будут формироваться в одном потоке, затем отдаваться одному или двум другим, которые уже непосредственно общаются с внешними устройствами  (дизайн условный, сделан для проверки возможностей проца, операционки и qt).
Обнаружил, что если передавать сообщения от первого потока с помощью системы сигнал/слот то загрузка процессора очень высокая (если отдавать сообщения одному потоку то ~1%, если двум то ~85%). Если же вместо системы сигнал/слот использовать семафоры то загрузка проца близка к 0.

Для проверки сделал два примера:

1.Пример 1
Первый поток спит 1 мс и затем шлет сигнал который связан со слотами задач выдающих данные в порт.

C++ (Qt)
void Data::run() {
    forever {
        usleep(1000);
        emit timeoutSignal();
    }
}
 

В потоке общающемся с внешним устройством (таких потока один или два) просто запускается цикл обработки сообщений и описан слот:

C++ (Qt)
void Port::run() {
    exec();
}
void Port::timoutSlot() {
    write_data_to_port();
}
 

Сигналы/слоты связаны так:

C++ (Qt)
int main(int argc, char *argv[])
{
    QApplication a(argc, argv);
    Data *data = new Data();
    Port *port1 = new Port(1);
    Port *port2 = new Port(2);
    QObject::connect(data, SIGNAL(timeoutSignal()), port1, SLOT(timeoutSlot()));
    QObject::connect(data, SIGNAL(timeoutSignal()), port2, SLOT(timeoutSlot()));
    port1->start();
    port2->start();
    port1->moveToThread(port1);
    port2->moveToThread(port2);
    data->start();
    return a.exec();
    data->quit();
    port1->quit();
    port2->quit();
}
 

2.Пример 2
Первый поток спит 1 мс и затем шлет семафор.

C++ (Qt)
void Data::run() {
    forever {
        usleep(1000);
        sem_post(sem);
    }
}
 

Второй поток (их один или два) ждет семафор и пишет в порт:

C++ (Qt)
void Port::run() {
    forever {
        sem_wait(sem);
        write_data_to_port();
    }
}
 

В первом примере загрузка проца ~85%, во втором близка к нулю. Оба варианта работают, данные передаются.
Все сигналы/слоты в первом примере выполняются в своих потоках - проверял.
Действительно ли система сигнал/слот настолько медленно работает или я что-то делаю не так?
Хотелось бы использовать сигналы/слоты поскольку в реальном приложении одному потоку потребуется обрабатывать разные сообщения от нескольких потоков и нельзя просто ждать один семафор. А проверять пришли ли сообщения в цикле не хочется.

>>Действительно ли система сигнал/слот настолько медленно работает или я что-то делаю не так?
тыц (http://doc.crossplatform.ru/qt/4.4.3/signalsandslots.html#slots)

to lit-uriy
можете выложить полный исходник теста?
тоже интересует этот вопрос...
наверное дело в том, что сигнал проходит  границу между потоками и тут есть еще больший оверхед.

>>можете выложить полный исходник теста?
гдеж я его возьму? Я дал ссылку на то место в документации, где я взял эту цитату.

Надо почистить оба примера, потом смотреть скорость. В 1-м случае connect происходит с DirectConnection, то что потом сделано moveToThread - не роялит. Значит 2 write_data_to_port  будут выполняться последовательно в главной нитке.
Лучше напр. сделать connect в начале Port::run с флагом QueuedConnection. Во 2-м примере семафор сработает верно  (приятнее использовать QSemaphore вместо sem_) но только 1 раз, дальше Data::run заканчивается.

Каждый write_data_to_port() выполняется не в главной нитке, а в контексте своего потока - проверял (выводил id потока в этой функции).

Верно подмечено, но на самом деле в функции run() есть цикл forever, я просто неправильно запостил пример.

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

Edit: также forever не решает проблемы - на каждый оборот цикла только 1 из 2-х Port сработает, который - случайно/невоспроизводимо

Протестив всё вдоль и поперёк выяснил, что проблема была в том что запускалась прога удаленно с
ключом -display VNC:0, который я использовал для того чтобы подключаться через vnc и смотреть ui.
Напомню, что это был qt embedded и прога для промышленного контроллера.
При таком способе запуска загрузка проца высокая:
exchange_test -qws -display VNC:0
А если запускать так:
exchange_test -qws
то загрузка проца близка к 0.
Еще остались вопросы, например, почему, при использовании ключа -display VNC:0,
загрузка проца так сильно зависит от количества задач ждущих сигнала (если одна то 1%,
а если две то уже 80-85%) или почему загрузки проца нет в случае с семафорами.
Но факт имеется.