Электронный миссионер

Суть такова: мне непрерывно сыпется поток данных. Я наполняю этими данными массив одним тредом. По какому-то признаку (длинна или время) я передаю указатель на этот массив обработчику данных в другой тред. Теперь мне надо создать новый массив, как я понимаю на новый указатель, т.к. Старый еще задействован. Вот тут меня и смутило, если к примеру данных будет поступать больше, чем будет успевать производится обработка, что делать с указателями? Создавать массив указателей?

From:

Фигня какая-то.
Зачем вообще первй тред нужен? Чисто для того чтобы переложить данные из одного места в другое? А нафига это делать?

From:

Элементарно Ватсон. У меня непрерывно сыпятся данные, одним тредом я делаю их предобработку и укладку в массивы. Второй тред или головная программа уже получает указатель на массив и начинает его обработку. Обработка по времени и ресурсам может занять даже большее время, чем их получение. При этом, после передачи указателя мы создаем другой массив и продолжаем получать данные. Вопрос, как быть с указателями. Вот мы передали один указатель, на другой создали массив и его тоже отдали на откуп, нужен еще один указатель. Увеличиваем время в бесконечность. И при этом не факт что предыдущий указатель освободился.

From:

1) Откуда они сыпятся?
2) Что за предобработка, зачем ее делать в отдельном треде?
3) Если данные сыплются непрерывно и обработка занимает больше времени чем получение - на каком-то этапе кончится память %)))
4) Почему именно массивы? Мот проще в файлы распихивать? Они как бы для того и придумывались %))

From:

Первые три вопроса мне не показались существенными. Данные получаю от МК. Обработка идет параллельно получению данных. Можно конечно сохранять и считать потом, но это не очень интересно и наглядно. Обработка много считает и ищет. Когда массив занимает 200 мегабайт, то даже самый быстрый алгоритм сортировки требует времени.

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

From:

Так данные же не по 200 мег приходят.
А пополнять отсортированный масив данными поддерживая его в отсортированном состоянии проще чем пересортировывать с нуля.
Да и вообще - можно деревья использовать - они для того и придумывались чтобы максимально быстро добавлять и искать данные. Правда там на оверхед надо смотреть - чтоб не получилось служебные данные занимают больше места чем полезные %)

ЗЫ. А еще бывают базы данных... %)

From:

maddev.livejournal.com

Очередь, синхронизированная по количеству элементов (пуста/не пуста) тем или иным образом. Плюс, диспетчер памяти должен быть thread-safe (чтобы не было соревнования между malloc() и free()).

From:

eddy-em.livejournal.com

Надо бы уточнять желаемое.
Насчет IPC советую почитать Стивенса: "UNIX: взаимодействие процессов".

From:

Я в комментариях выше пояснил что хочу. За наводку на книгу спасибо

From:

mbr.livejournal.com

Да, это очередь.

В сях очередь, вероятно, придется велосипедить. Рекомендуется сделать в самой очереди:

- в методе send(), при превышении длины очереди усыплять текущий тред
- в методе receive() засыпать, пока не поступит сообщений.

Тогда никакой синхронизации тредов не потребуется. Да, если известна длина объектов, память лучше выделить сразу под все объекты.

From:

Не совсем понял что за задачу ты хочешь решить.
А критично использование ANSI C? Если не критично, то я посоветовалбы использовать thread-safe queue из TBB (например).

From:

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

From:

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

From:

Не понял про перепаковки и зачем они нужны? Подтверждать некому, данные идут с датчиков в контролер, который из потом уже шлет в комп по цифре.

From:

Ты используешь динамические массивы в чистом виде, поэтому когда данных прилетело больше чемты выделил под них места, придется расширять размер выделенной под них памяти, вот тут и вылазит необходимость перепаковки данных, а операция эта крайне не быстрая. И тут появляется еще эффект "снежного кома" если это можно так назвать, чем больше данных будет принимать за раз второй поток, тем дольше он будет работать, а значит тем больше прилетит за это время данных в первый поток и тем больше таких перепаковок придется там делать. Ну и во время этого процесса первый поток будет заниматься расширением своей памяти и данные прилетающие к нему доставленны не будут, а потеря данных скорей всего критична тут. Это пожалуй тут самая глобальная проблема тут будет. Ну и соответственно о хорошем перформансе алгоритма говорить тут не приходится.

From:

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

From:

На тему более простого пути, как я написал выше удобней использовать TBB'шные контейнеры. По поводу дальнейшего использования указателя, сворей всего будет просто адский data race и потеря данных с которыми бороться очень сложно.

From:

Погляжу в эту область, спасибо

From:

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

From:

У меня задача данные обрабатывать порциями. Так что тут циклический буфер не очень подходит

From:

Циклический не нужен, достаточно filo очереди без закольцованности

From:

Без циклического буфера придется или данные в памяти двигать или память ресайзить - и то и то весьма медленно.
Ну или постоянно выделять память и складывать указатели в ФИФО на основе списка. Опять же - выделение памяти не самая быстра операция.

Edited Date: 2012-06-05 05:40 pm (UTC)

From:

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

From:

Ну как бы да.
Все давным давно написано до нас.
Главное правильное средство выбрать.

From: