QtConcurrent::run() многоразовый вызов, очередность получения QFuture::result()

Задача следующая - есть файл, большой файл. Нужно провести по нему определенные операции - декодирование. Однопоточно это делать медленно, соответственно многопоточность реализована через QtConcurrent.

Для решения я пробовал:
И
В обоих случаях, что
, что
Выдает первым не то будущее, которое было запущенно, а то, которое пришло первым! Т.е. принимаемые части могут меняться местами. В однопоточном режиме, когда запускается только один объект будущего, все работает как надо.

Вопрос, как заставить их приходить в порядке запуска?

Пробовал работать с QtConcurrent::mapped(), но проблема в том, что map требует QFuture той-же размерности, что и Sequence, а я передаю в потоки не сам массив данных, прочитанных из файла, а позицию в файле. Файл читается по мере обработки. Если же передавать массив данных - при вызове map, файл просто целиком попытается грузануться в память. Это проблема.

QtConcurrent::mappedReduced() не подходит по той причине, что декодируемые блоки могут рваться и, как результат, надо будет останавливать все это дело и начинать поиск последовательности где-то в середине блока.

QtConcurrent::run() в данном случае подходит отлично, кроме того момента, что будущие результаты возвращаются не в том порядке. Как можно решить эту проблему?

0

Вы говорите сначала одно потом другое, вас фиг поймешь о чем вы.

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

0

Сообщение от TRam_ Либо же, зная примерный размер доступной памяти, запускать потоки для таких кусков, которые явно уместятся в памяти, дождаться завершения всех 4 потоков, записать результаты всех 4 в файл, потом переходить к следующим кускам. Так, мне кажется, будет оптимально.

Примерно так и делается. Запускать задач можно много - Qt Concurrent заботится о том, что работает одновременно максимальное количество задач, которое может проглотить система. Есть же они начинают только в тот момент, когда прочтут файл, который уже находится в потоке. Так что ситуация, когда чтение файла внутри потоков, ест гораздо меньше памяти. Результаты складывать в дополнительный массив не могу по той-же причине - все это хочет кушать, плюс копирование - самая медленная операция. Мне же нужно минимизировать время. Но решение есть - просто проходить по всем результатам в синхронайзере пока не будет нужный блок данных с нужным свойством/признаком. Тогда его забирать и искать следующий с начала.. Походу придется делать так, раз решения по самому QFutureSynchronizer нет..

Добавлено через 2 минуты

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

Я с самого начала говорю все то-же самое. Проблема одна. Видимо вам надо читать внимательнее.

0

Сообщение от Amok Я с самого начала говорю все то-же самое. Проблема одна. Видимо вам надо читать внимательнее.

Проблема одна, но говорите вы об разных вещах.
Одно дело порядок выполнения потоков, другое дело порядок фьюче в контейнере.

0

Сообщение от Avazart Проблема одна, но говорите вы об разных вещах. Одно дело порядок выполнения потоков, другое дело порядок фьюче в контейнере.

Я говорю о том, что порядок фьючей в контейнере - не тот. В самом первом посте это было написано! Я не знаю как вы читали. И документация и пример говорят о том, что должно работать по другому. Я, собственно, и пришел сюда что бы спросить причину, а не обсуждать знаю ли я как работают потоки или кто из нас двоих пишет говнокод, а кто нет. Если не знаете причину - так и напишите - я не знаю, такие вещи я не писал.

Сигналы, кстати, будут работать медленнее. А скорость выполнения у меня - на первом месте.

0

Сообщение от Amok Я говорю о том, что порядок фьючей в контейнере - не тот.

На что я ответил что такого не может быть, и у вас кривой код.

Добавлено через 27 секунд

Сообщение от Amok Сигналы, кстати, будут работать медленнее.

Экономия на спичках.

0

Сообщение от Avazart На что я ответил что такого не может быть, и у вас кривой код.

Я очень рад. Мне это очень помогло. Код приведен. Явной ошибки там, я так понял, вы тоже найти не смогли.

Сообщение от Avazart Экономия на спичках.

Эти "спички" позволили мне время обработки файла в 4 потоках сократить с 8 минут до 5. Конечно - львиная доля это копирование контейнеров, но на таком объеме даже малая экономия может дать ощутимый прирост. В юбом случае я буду пробовать разные варианты и выберу тот, который мне подойдет больше.

0

Сообщение от Amok вы тоже найти не смогли.

Я перестал смотреть ваш код когда увидел быдлокод с QCoreApplication:rocessEvents();
(который тоже позволяет выполнятся слотам и тоже "жгет ваши спички")

Вы его выпиливать отказались, на чем разговор закрыт.

0

Avazart, а схрена-ли я должен выпиливать то, что не имеет отношения к заданному вопросу? Вы уверены что правильно прочитали вопрос темы? Объясните тогда, как QCoreApplication:rocessEvents(), находящийся в другом месте, связан с вопросом темы?)

QCoreApplication:rocessEvents() можно вообще удалить и не чистить память. Но проблемы это - не решит.

0

Если вы написали код,в соответствии с доками,а он не работает, и уверены,что вашей ошибки нет-напишите разработчикам.
Оставьте заявку на bug traacker-е.
В течении недели ответят.
Если, то, что вы говорите правда,и проблема в QT- надо исправлять.
(тем более управление потоками-критичная секция)

Лично напарывался на такие проблемы.

0

0

saqef, пожалуй. Всем спасибо за ответы!

Добавлено через 6 минут

Сообщение от Avazart Не по теме: Да проблема не в Qt а в кривых руках, это уже выяснили.

Кстати, если делать сигналами, то придется тоже делать вызов QCoreApplication:rocessEvents() в обработчике сигнала, если поток 3 придет раньше потока 2. Просто что бы обработчик не "повис" и дал прийти сигналу со вторым куском. Либо класть все это куда-то в другой массив, но это уже снова сильно жрет память. Я этого делать избегаю.

0

https://www.cyberforum.ru/blog... g4909.html

0

Сообщение от Avazart https://www.cyberforum.ru/blog... g4909.html

Это все я знаю. Приложение - консольное. Ни форм, ничего нет. Единственный ввод - указание источника и вывода. Никаких лишних сигналов туда не попадает. Хотя, конечно, можно было написать и EventLoop:rocessEvents(), это, и правда, было бы корректнее, даже с учетом моих особенностей. Или вообще QAbstractEventDispatcher:rocessEvents( ). Но в моем случае это проблем не вызывает. Вызывается этот обработчик, когда работа должна быть остановлена и только тогда, при отмене обработки. Это видно в коде.

0

Сообщение от Amok Это все я знаю.

А чего тогда припераетесь ? Выпилите нафиг processEvents() ...

Сообщение от Rius Если в коде есть DoEvents (Qt и .Net) или ProcessMessages (Delphi/C++ Builder), значит это говнокод и его надо переписать. Причём это не сами методы плохие, а их применение говорит о недостатке знания более правильных способов.

Сообщение от Amok Но в моем случае это проблем не вызывает.

Уверены? Почему тогда работает криво ?

0

Сообщение от Avazart А чего тогда припераетесь ? Выпилите нафиг processEvents() ... Уверены? Почему тогда работает криво ?

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

0

Сообщение от Amok НЕ приводит к исправлению работы.

Это само по себе ошибка.

0

Косяк был в алгоритме, QFutureSynchronizer отрабатывал как надо. Всем спасибо.

0