Как это? Приходят пакеты из одно порта и ретранслируются в другой (по разным протоколам).
И всё это гипотетически реализовано через кучу. Вдруг выходной канал отваливается, а на входе поток не прерываем (так случилось).
А вы продолжаете создавать на куче пакты, пока она не закончится.
Вопрос: как вам применение кучи поможет на этапе компиляции? (отвечайте пожалуйста конкретно и не юлите)

Только не надо меня кормить этими дежурными фразами, что не надо, а что надо...

Хороший пример
При использовании кучи не возникнет никаких странных багов. Просто malloc() будет возвращать ноль вместо поинтера на область памяти. Если апликация написана грамотно, то будет выдано сообщение об ошибке, ну и работа устройства будет остановлена до устранения проблемы, после которого устройство продолжит свою работу.
На этапе компилляции я буду знать, что случится именно так и требуемая память не будет взята у чужого сегмента.

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

Скажите, у вас создалось впечатление, что я уклоняюсь от ответов на какие-то ваши вопросы? Укажите мне на эти вопросы и вы увидите, что ваше впечатление ошибочно. Я прадоставлю вам исчерпывающий ответ.

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

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

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

Я в подобных случаях поступал следующим образом:
создавал на оставшуюся свободной области памяти массив элементов. Размер элемента равен максимально возможному сообщению. Далее создавал функции для запроса элемента и возвращения элемента. Все элементы имели заголовок для соединения их в односвязные списки. Пул свободных элементов тоже был оформлен как список.
Забавная история спучилась с Микрочипом. Компилятор молча укоротил мой массив до конца страницы адреса. В Микрочипе страничная адресация это бич. За что я люблю aтмелевские процессоры -- они свободны от этого нонсенса.





Приведите мне сценарий решения задачи, поставленной demiurg_spb в случае с затыком выходного потока. При условии, что буферы берутся на стеке.



Сообщение отредактировал Tarbal - Sep 13 2013, 14:13

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

Во-первых пример не мой, а во-вторых я не знаю как рекурсия поможет. Знаю, что она убьёт содержимое памяти.
Давайте подождем автора примера. Я надеюсь у него есть сценарий.

Вопрос к вам. Я правильно вас понял? Для того, чтобы с созданием массивов в стэке не было проблем надо быть аккуратным с их использованием? Или для этого надо предпринять какие-то меры?




Посреди улицы разговаривают два одессита. К ним подходит третий. Долго молча слушает, затем резко разворачивается и, уходя, говорит: – Ой! Та не морочьте мне голову…

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

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

"А без рекурсии не получится. Ведь по условию задачи"
Только я противоречие в ваших же словах вижу ? Вы не знаете, как она поможет, но уверены, что без нее не получится ?

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

Конечно создаётся, вы ведь так и не смогли сказать, что использование кучи, в приведённом мной примере, на этапе компиляции вам никак не поможет. А про рекурсию - это уже ваши домыслы. Я не предлагал ничего подобного никогда. Извините, но с вами очень трудно разговаривать. Я об одном спрашиваю а вы всё продолжаете быть на своей волне. Разрешите откланяться!

+100500 Слишком много додумываний и предположений...

О! Вы появились. Прокоментируйте, пожалуйста мой ответ #17 на ваш #16.



Сливаете?


Виноват, домыслил.
Тогда к вам вопрос.

Приходят пакеты из одно порта и ретранслируются в другой (по разным протоколам).
И всё это гипотетически реализовано через stack.
Пока передается сообщение, на вход приходит следующее. Как быть?



Сообщение отредактировал Tarbal - Sep 13 2013, 15:34

Вобщем malloc использовать стал в микроконтролерах когда у них стало 512 метров ддр внешней. И честно говоря все равно неспокойно. Фрагментация вещь непредсказуемая, но при таких объемах можно считать вероятность отказа незначительной.Это не значит, что нужно отказывать от дин. выделения в мелких, но не родным аллокатором. Говорить о куче в контексте когда все озу килобайт — смешно имхо. Да и не надо было, это же не вебсервер непредсказуемый, да и цена отказа моих программ высоковата, поэтому только стек + статические выделенные буфер ы. Да, никаких вызовов stdlib из прерываний.


Мне кажется Вы слово рекурсия неверно понимаете. А описанную задачу решают с помощью двойной буферизации, пока один буфер принимает — он только принимает.Как заполнен — идет его обработка, а на прием подставляется второй.Совершенно общая практика, начиная от контроллера SPI на верилоге и заканчивая V4L video for Linux.

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

Не слишком ли сложно?

Может проще malloc() или еще проще тот метод, который я описал.

Или как-то иначе можно?

Сообщение отредактировал IgorKossak - Sep 13 2013, 16:07