Все ее могут и никогда не разлочить. Нужно пользоваться моментом.

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

Если дефрагментация выполняется в потоке с самым низким приоритетом (как и должно быть) - то откуда грабли?

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

В старых книгах по Windows писали что о-го-го. Но когда появились процессоры с аппаратной поддержкой страниц памяти (80386) то эту систему отменили.


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

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

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

А вот пример:


Если после генерации сообщения поток блокируется, (у меня лично таких случаев 100%) вплоть до момента обработки, вообще кучу использовать не надо. А всё, что не успевает обрабатываться продюсер/консюмером - вообще выносится за ось, поскольку ставит под сомнение перфоманс этой оси. Я имею ввиду - пытаюсь обходиться одним тредом.

Сообщение отредактировал _Pasha - Jun 21 2012, 07:41

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

Забыли по вариант 3: объект, например, контент сообщения, создается как локальный, т.е. в стеке, а в очередь записывается указатель на него. Затем отправитель сообщения блокируется до обработки, по окончании обработки работа возобновляется, тело сообщения удаляется из стека при выходе из блока кода.

Ну тут я вижу потенциальную проблему. Допустим памяти 100 байт. Есть две задачи. Сообщение занимает 100 байт. Какой стек вы выделите каждой задаче? Правильно по 100 байт и того получается 200, уже не влазим. Если есть куча, то система работоспособна. Разумеется память используется по очереди.
Т.е. я хочу сказать что при использовании стека в качестве хранилища данных, мы должны зарезервировать его максимальный размер при старте. Т.е. это первый вариант.

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


Ну да, было дело Вероятность схватить Deadlock резко возрастает и тормоза в том числе. в 21 веке никто так не делает...


а как себя оправдала Windows 3.1 16-bit? :D


Это убивает прелесть многопоточности и "естетственности" программы. весь смысл прогонки обьекта по нескольким потокам - избавится от гемора, избавится от локов, упростить программу. попишу немного букавок в качестве примера.
Есть GSM модуль, протокол CMUX - 2 канала GSM & GPRS. Каждий канал обрабатывается только своим потоком.
Допустим GSM опрашівает состояние модуля, что-то там куда-то логирует и принимает и отправляет SMS. В SMS приходят команды. Допустим, пришла команда загрузить какой-то файл s ftp://ftp.murzilka.ru/01.zip. GSM формирует обьект-сообщение и кидает в очередь. GPRS по мере готовности выгребает сообщение и выполняет. в конце кидает его обратно в очередь(вернее само сообщение себя кидает и меняет состояние, эт уже детали реализации иерархии классов) и занимается дальше своими делами.
GSM по мере готовности выгребает сообщение и выполняет(отправляет SMS с отчетом о загрузке файла).
Конечно, можно было лочить каналы(довольно медленные) и делать все действия на месте(не отходя от кассы), но в сложном приложении(в том,которое есть на самом деле, все гораздо сложнее) запаритесь потом и система будет простаивать.на пример, чтобы прочитать следующую смс(вообще не относящуюся к командам связанным с GPRS) или снять следующее состояние модема надо будет ждать, пока тормознутый GPRS что-то там обработает минут так 10-15:))


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

Deadlock - вряд ли. Так как GlobalLock не предоставляет блок в исключительное пользование одному процессу. Много процессов могут вызвать GlobalLock для одного и того же блока одновременно - и получат успешно в ответ один и тот же указатель. GlobalLock блокирует только перемещение блока при дефрагментации.

Вещь! была для своего времени. Впрочем эта система выделения памяти была действительно актуальна только до Windows 3.0 включительно, на процессоре 8086. Windows 3.1 на таком процессоре уже не могла работать.

легко: Поток 1 занял взял GlobalLock, ожидает сообщение от потока 2. Поток 2 готов давать сообщение, для этого ему надо выделить блок памяти. куча фрагментирована, блока памяти нужного размера нету,другие блоки тоже двигать нельзя. дедлок готов. Такое может произойти,если приложение выделяет память в "peaks"-режиме. допустим wait и GlobalLock в потоке 1 поменять нельзя просто так.

Во-втором случае будет простаивать как минимум в 2 раза большее кол-во памяти.
Все кучефилы почему-то забывают об элементарной вещи, которая сводит на нет все +-ы кучи в embedded:
если к примеру 2 потока используют периодически каких-то 2 блока памяти и зависимость во времени этих использований невозможно детерминировать и возможны моменты одновременного использования (т.е. - невозможно поместить эти 2 блока в union static), то они совершенно забывают, что если выделять эти блоки на куче, то тоже будут моменты одновременного использования, соответственно - объём памяти в куче должен быть равен не менее чем сумме размеров блоков (а в реальности - более из-за заголовков).
Поэтому в типичном эмбеддед-приложении где нет запускаемых пользователем задач (которым при нехватке памяти можно отказать в запуске) или если нет таких потоков, выполнение которых можно остановить без ущерба функционированию системе при нехватке памяти, использование кучи не приводит к уменьшению требований по памяти, а наоборот - увеличивает требования к памяти + приводит к проблемам фрагментации.
Поэтому обычное static-размещение + union для использований неперекрывающихся по времени, однозначно рулит.
Поймите-же эту простую мысль, кучефилы, и творения ваши станут чуть менее глючными!!!