Опять потоки!

[kuzulis]

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

ну да... потоки ThreadRead которые были вызваны методом A::m_A->readData(111,12,1, manual=true, &data) или
потоки ThreadWrite вызванные A::m_A->writeData(111,12,1, const &data)сделают свое дело и завершатся! а поток polling останется в работе "вечно"

И иначе то никак нельзя поступить.. т.к. ресурс - допустим последовательный порт - он то один!   И за одну транзакцию необходимо сделать запрос/ответ !!!

и зачем вообще постоянно сигналить о том, что данные прочитались/обновились?

не обновились - а ИЗМЕНИЛИСЬ! на какую то величину.. например читая такой параметр как "Напряжение" если "зона" стоит = 1 Вольт, прочитали 220 Вольт, а до этого было 221 вольт  - то съэмиттится сигнал со значением = 220 Вольт и обновится значение в структуре

и если что - можно "прицепится" или к сигналу.. или "тупо" читать структуру

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

нет нет нет! Сигнал о том что данные изменились!!!!! с указанием ID канала, ID узла, ID данных и их значением!

[kuzulis]

ведь это никого не интересует.

Это интересует ЯДРО моей "системы"...

Ядро имеет массивы объектов типа "точка" ...
"Точка" - имеет такие параметры как:
1. UID - уникальный идентификатор
2. Имя - текстовая строка (например "Мощность на фазе А")
3. Описание - текстовая строка (например "Мощность на фидере №1")
4. Тип данных - (Int, bool, float и т.п.)
5. Ссылка на источник данных - это кодированная ссылка например на объекты класса А , т.е по этой ссылке из класса А можно получить данные
(например Link = P_ID, CH_ID, NODE_ID, DATA_ID
где
P_ID - идентификатор протокола (класса А)
CH_ID - ид. канала в классе (объекте, протоколе и т.п.)
NODE_ID - ид. узла в канале
DATA_ID - ид. данных в узле
...
..

Ядро с этой ТОЧКОЙ производит различные манипуляции (обрабатывает её значение, пересчитывает диапазоны, уставки, алармы, варнинги и т.п и. т.д )
т.е. клиентом класса А является ЯДРО! А класс А - для ядра - просто источник данных для точек ядра !

[ритт]

kuzulis, прекращай постить мессаги один за другим - создаётся впечатление, что сам себе что-то доказываешь...

ну да... потоки ThreadRead которые были вызваны методом A::m_A->readData(111,12,1, manual=true, &data) или
потоки ThreadWrite вызванные A::m_A->writeData(111,12,1, const &data)сделают свое дело и завершатся! а поток polling останется в работе "вечно"

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

[kuzulis]

Я разобраться пытаюсь.. и ничего не доказываю

когда есть такая замечательная штука как очередь?

ну например как это с очередью сделать? конкретный примерчик пжлста в коде (набросок)

[ритт]

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

[kuzulis]

это тут ?

http://doc.trolltech.com/main-snapshot/qthreadpool.html

[ритт]

его в доках нет, оно есть в сорцах.

[kuzulis]

где? так и искать? фарлингфреххренессер?

[BRE]

где? так и искать? фарлингфреххренессер?

QFileInfoGatherer