aaarrr 69 20 июня, 2012 Опубликовано 20 июня, 2012 · Жалоба Пока все не разлочат кучу, её не дефрагментируешь. Все ее могут и никогда не разлочить. Нужно пользоваться моментом. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Beginning 0 20 июня, 2012 Опубликовано 20 июня, 2012 · Жалоба Не ну я прикидывал, мол если например кусок не разлочен в конце, а в начале все разлоченные, то можно только начало дефрагментировать, но это такие грабли, что и работать будет соответствующе. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
_Pasha 0 20 июня, 2012 Опубликовано 20 июня, 2012 · Жалоба Не ну я прикидывал, мол если например кусок не разлочен в конце, а в начале все разлоченные, то можно только начало дефрагментировать, но это такие грабли, что и работать будет соответствующе. Если дефрагментация выполняется в потоке с самым низким приоритетом (как и должно быть) - то откуда грабли? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Beginning 0 20 июня, 2012 Опубликовано 20 июня, 2012 · Жалоба Ну хотябы, если дефрагментация началась, то её уже не остановить наполовину, и в этот момент если более приоритетному потоку надо что то сделать то он этого не сделает - тоесть все остальные потоки автоматически становятся с более низким приоритетом. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
maksimp 0 21 июня, 2012 Опубликовано 21 июня, 2012 · Жалоба Зарезервировал память. Хочеш попользоваться -получай поинт, пользуйся. Не пользуешся разлочивай. .... Ну и как эта система, себя оправдала? В старых книгах по Windows писали что о-го-го. Но когда появились процессоры с аппаратной поддержкой страниц памяти (80386) то эту систему отменили. Все ее могут и никогда не разлочить. Нужно пользоваться моментом. Подозреваю что использование памяти должно быть тогда организовано более определённым образом. Например, система реального времени может иметь общий цикл приёма, обработки и передачи информации, например длительностью 100 мс. К концу цикла все блоки обязаны быть разлочены, и производится дефрагментация. Если не все блоки разлочены оказались - то фатальная ошибка, прекращаем сбрасывать сторожевой таймер и уходим в аппаратный сброс. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
_Pasha 0 21 июня, 2012 Опубликовано 21 июня, 2012 · Жалоба Ну хотябы, если дефрагментация началась, то её уже не остановить наполовину Пересылку блока надо делать атомарной :laughing: А так - необходимость в том, чтобы к запуску дефрагментации были разлочены все блоки, еще обосновать надо, с точки зрения временнОй эффективности работы дефрагментатора. Очень может быть, что "таская" блоки по одному система ничего не проиграет. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Beginning 0 21 июня, 2012 Опубликовано 21 июня, 2012 · Жалоба Наверняка так и есть. Но по поводу этого я не сильно переживаю, тут более менее всё понятно. Сильно напрягает наложение специальных требований на программу. Это основной костыль. Любые за уши притянутые паттерны я расматриваю как зло. Программа должна быть максимально естественна (проста) с точки зрения кода. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
_Pasha 0 21 июня, 2012 Опубликовано 21 июня, 2012 (изменено) · Жалоба Программа должна быть максимально естественна (проста) с точки зрения кода. А вот пример: Применяется для хранения сообщений для передачи между потоками... Типа в одном потоке создаем обьект в куче, кидаем указатель на него в FIFO, другие потоки выгребают эти обьекты, выполняют соответствующие методы, возможно передают их дальше другим потокам(в том числе и родителю обратно) и подостижении состояния "final" обьект удаляется(это может произойти в любом потоке). Размер обьектов разный, тип разный. FIFO один. Лучшей реализации,чем использовать кучу пока не придумал. Если после генерации сообщения поток блокируется, (у меня лично таких случаев 100%) вплоть до момента обработки, вообще кучу использовать не надо. А всё, что не успевает обрабатываться продюсер/консюмером - вообще выносится за ось, поскольку ставит под сомнение перфоманс этой оси. Я имею ввиду - пытаюсь обходиться одним тредом. Изменено 21 июня, 2012 пользователем _Pasha Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Beginning 0 21 июня, 2012 Опубликовано 21 июня, 2012 · Жалоба Я не очень понимаю выражения "не использовать кучу". Тут 2 варианта, либо ты резервируешь память раз и навсегда, либо динамически выдаёш, забираеш. В первом варианти торетически память в большинстве случаев будет простаивать. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
_Pasha 0 21 июня, 2012 Опубликовано 21 июня, 2012 · Жалоба Я не очень понимаю выражения "не использовать кучу". Тут 2 варианта, либо ты резервируешь память раз и навсегда, либо динамически выдаёш, забираеш. В первом варианти торетически память в большинстве случаев будет простаивать. Забыли по вариант 3: объект, например, контент сообщения, создается как локальный, т.е. в стеке, а в очередь записывается указатель на него. Затем отправитель сообщения блокируется до обработки, по окончании обработки работа возобновляется, тело сообщения удаляется из стека при выходе из блока кода. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Beginning 0 21 июня, 2012 Опубликовано 21 июня, 2012 · Жалоба Ну тут я вижу потенциальную проблему. Допустим памяти 100 байт. Есть две задачи. Сообщение занимает 100 байт. Какой стек вы выделите каждой задаче? Правильно по 100 байт и того получается 200, уже не влазим. Если есть куча, то система работоспособна. Разумеется память используется по очереди. Т.е. я хочу сказать что при использовании стека в качестве хранилища данных, мы должны зарезервировать его максимальный размер при старте. Т.е. это первый вариант. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
brag 0 21 июня, 2012 Опубликовано 21 июня, 2012 · Жалоба Я уже писал про **p. Придётся везде лепить. А потом начнётся ***p и т. д. к тому же перегруженные, а возможно и volatile - защищать это все дело надо будет в многопоточном приложении... GlobalUnlock. Ранее полученный указатель стал недействительным. Когда блок отпущен он можен быть сдвинут. Чтобы ещё раз добраться до блока нужно ещё раз вызвать GlobalLock. Ну да, было дело ;) Вероятность схватить 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 байт(+ оверхед на заголовки): Раз у вас не хватает памяти чтобы распределить её в виде static или на стеке для всех потоков, значит возможна ситуация (и даже с большей вероятностью), когда много потоков запросит больше памяти чем есть. С наличием служебных полей управления блоками в heap и фрагментации это даже более вероятно, чем при static размещении. Что ваша система должна делать при этом? Выдать отказ потоку (но значит алгоритм всех потоков должен рассчитывать, что может быть получен отказ в памяти)? Или приостановить выполнение потока (но может случиться dead-lock)? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
maksimp 0 21 июня, 2012 Опубликовано 21 июня, 2012 · Жалоба GlobalUnlock. Ранее полученный указатель стал недействительным. Когда блок отпущен он можен быть сдвинут. Чтобы ещё раз добраться до блока нужно ещё раз вызвать GlobalLock. Ну да, было дело ;) Вероятность схватить Deadlock резко возрастает и тормоза в том числе. Deadlock - вряд ли. Так как GlobalLock не предоставляет блок в исключительное пользование одному процессу. Много процессов могут вызвать GlobalLock для одного и того же блока одновременно - и получат успешно в ответ один и тот же указатель. GlobalLock блокирует только перемещение блока при дефрагментации. а как себя оправдала Windows 3.1 16-bit? :D Вещь! была для своего времени. Впрочем эта система выделения памяти была действительно актуальна только до Windows 3.0 включительно, на процессоре 8086. Windows 3.1 на таком процессоре уже не могла работать. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
brag 0 21 июня, 2012 Опубликовано 21 июня, 2012 · Жалоба Deadlock - вряд ли. легко: Поток 1 занял взял GlobalLock, ожидает сообщение от потока 2. Поток 2 готов давать сообщение, для этого ему надо выделить блок памяти. куча фрагментирована, блока памяти нужного размера нету,другие блоки тоже двигать нельзя. дедлок готов. Такое может произойти,если приложение выделяет память в "peaks"-режиме. допустим wait и GlobalLock в потоке 1 поменять нельзя просто так. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 242 22 июня, 2012 Опубликовано 22 июня, 2012 · Жалоба Я не очень понимаю выражения "не использовать кучу". Тут 2 варианта, либо ты резервируешь память раз и навсегда, либо динамически выдаёш, забираеш. В первом варианти торетически память в большинстве случаев будет простаивать. Во-втором случае будет простаивать как минимум в 2 раза большее кол-во памяти. Все кучефилы почему-то забывают об элементарной вещи, которая сводит на нет все +-ы кучи в embedded: если к примеру 2 потока используют периодически каких-то 2 блока памяти и зависимость во времени этих использований невозможно детерминировать и возможны моменты одновременного использования (т.е. - невозможно поместить эти 2 блока в union static), то они совершенно забывают, что если выделять эти блоки на куче, то тоже будут моменты одновременного использования, соответственно - объём памяти в куче должен быть равен не менее чем сумме размеров блоков (а в реальности - более из-за заголовков). Поэтому в типичном эмбеддед-приложении где нет запускаемых пользователем задач (которым при нехватке памяти можно отказать в запуске) или если нет таких потоков, выполнение которых можно остановить без ущерба функционированию системе при нехватке памяти, использование кучи не приводит к уменьшению требований по памяти, а наоборот - увеличивает требования к памяти + приводит к проблемам фрагментации. Поэтому обычное static-размещение + union для использований неперекрывающихся по времени, однозначно рулит. Поймите-же эту простую мысль, кучефилы, и творения ваши станут чуть менее глючными!!! :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
