Здравствуйте, SeninAndrew, Вы писали:
SA>Здравствуйте, deadSLAYER, Вы писали:
SLA>>Все кучи делят одно адресное пространство, если предположить, что адресные пространстав разных куч не пересекаются, SLA>>а идут последовательно, можно просто запоминать диапазон значения указателей а-ля: SLA>>куча-раз — 0x1324- SLA>>куча-два — 0x4657- SLA>>Потом когда делиту приходит указатель можно попробовать по значению понять из какой он кучи. SLA>>вот.
SA>Интересная идея, только как вот узнать эти диапазоны ...
После создания кучи выделить 8 байт памяти
После создания другой еще 8 байт,
проверить опытным путем все ли указатели получаемые из первой кучи лежат между этими тестовыми указателями,
если все — считай что решение готово — при создании кучи делает "тестовый" аллокейт,
и сохраняешь эти значения, потом смотришь бинарным поиском между какими двумя находится поинтер и получаешь номер кучи.
Re[10]: Перегрузка new/delete, хранение "метки" для выделенн
Vain wrote:
> ME>Vain wrote: > >> > V>>Есть куча, я помню что в куче нельзя выделить больше определённого >> > размера, вроде 2GB, а так как она виртуальная, то мы имеем дело просто с >> > "адресным пространством", которое както там мапиться менеджером памяти >> > на физические страницы. > > ME>Несколько не так. > > ME>Если ты хочешь использовать больше памяти, чем размер адрессного > пр-ва процесса, > ME>тебе придется переключать проекции. Так делалось на zx spectrum 128k > с 16-битным > ME>адрессным пространством, где чтобы доступится к памяти больше 64k, > приходилось > ME>переключать две страницы, отображенные на 0x4000-0x7fff и > 0xc000-0xffff. Т.е. > ME>размер виртуального адрессного пространства ограничивает лишь объем > памяти, к > ME>которому ты можешь доступиться одновременно.
> Всё равно не понял, а как ты будешь переключать страницы, через что? > Пример какойнить приведи этого.
Создай несколько проекций (CreateFileMapping/shm_open). Отображай их
(MapViewOfVileEx/mmap) поочередно на один и тот же виртуальный адрес. С PAE не
работал, но там похожие вызовы.
(на spectrum это делалось выводом байта в непомню какой порт)
> ME>Выделить можно, но придется жонглировать отображаениями. Т.е. > указатели на > ME>объекты в этих отображениях, должны помимо адреса также идентифицировать > ME>конкретную проекцию. Иными словами эмулировать более "широкое" адрессное > ME>пространство.
> А это возможно в рамках одного процесса?
Про один процесс и речь.
-- Maxim Yegorushkin
No Microsoft product was used in any way to write or send this text.
If you use a Microsoft product to read it, you're doing so at your own risk
Posted via RSDN NNTP Server 2.0
Re[11]: Перегрузка new/delete, хранение "метки" для выделенн
Здравствуйте, MaximE, Вы писали:
ME>Создай несколько проекций (CreateFileMapping/shm_open). Отображай их ME>(MapViewOfVileEx/mmap) поочередно на один и тот же виртуальный адрес. С PAE не ME>работал, но там похожие вызовы.
А, так ты имеешь ввиду свой менеджер написать? Я так понял что этот кусок пямяти должен обязательно быть Locked в на физическую память иначе будет двойной свап (сначала винды, а потом через мой менеджер)?
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Re[3]: Перегрузка new/delete, хранение "метки" для выделенно
Здравствуйте, SeninAndrew, Вы писали:
SA>Здравствуйте, Risk Server, Вы писали:
RS>>А в чём вообще смысл подобной оптимизации? Поскольку удаление возможно из произвольного потока всё равно прийдётся синхронизироваь _все_ операции с кучей.
SA> И синхронизация нужна только в том случае, когда поток А удаляет память из кучи потока В. А это случается существенно реже, чем удаление собственной памяти (из своей кучи).
Правильно. НО когда поток А удаляет память из своей собственной кучи, ему тоже надо синхронизироваться с потоком В, который то же самое время может удалить память из кучи потока А. То есть необходимо входить в критическую секцию при каждой операции с кучей, не зависимо своя она или чужая.
Я не спорю, что при заведении нескольких куч в большей части случаев синхронизация эта обойдётся дёшево ибо критическая секция будет свободна.
Но поскольку синхронизация нужна,то получается что знать чья куча совсем не надо. Удаление памяти из своей и из чужой кучи должно выглядеть абсолютно одинаково.
SA>Более того. Если быть совсем точным, то собственные секции можно и не заводить, так как на уровне каждой кучи синхронизация обеспечена системой.
Ну это опционально, как попросите. Мой поинт в том, что синхронизация нужна. Лучше конечно использовать ту, что система сама предоставляет.
Re[4]: Перегрузка new/delete, хранение "метки" для выделенно
Здравствуйте, deadSLAYER, Вы писали:
SLA>Здравствуйте, SeninAndrew, Вы писали:
SA>>Здравствуйте, deadSLAYER, Вы писали:
SLA>>>Все кучи делят одно адресное пространство, если предположить, что адресные пространстав разных куч не пересекаются, SLA>>>а идут последовательно, можно просто запоминать диапазон значения указателей а-ля: SLA>>>куча-раз — 0x1324- SLA>>>куча-два — 0x4657- SLA>>>Потом когда делиту приходит указатель можно попробовать по значению понять из какой он кучи. SLA>>>вот.
SA>>Интересная идея, только как вот узнать эти диапазоны ...
SLA>После создания кучи выделить 8 байт памяти SLA>После создания другой еще 8 байт, SLA>проверить опытным путем все ли указатели получаемые из первой кучи лежат между этими тестовыми указателями, SLA>если все — считай что решение готово — при создании кучи делает "тестовый" аллокейт, SLA>и сохраняешь эти значения, потом смотришь бинарным поиском между какими двумя находится поинтер и получаешь номер кучи.
почти уверен что куча виндоуз не гарантирует непрерывного диапазона адресов для всех блоков памяти, выделенных из кучи. Пока размер кучи мал — это будет работать, но со временем куча начнёт расти за счёт выделения новых регионов памяти и данные метод работать перестанет.
Re[4]: Перегрузка new/delete, хранение "метки" для выделенно
Здравствуйте, Risk Server, Вы писали:
RS>Правильно. НО когда поток А удаляет память из своей собственной кучи, ему тоже надо синхронизироваться с потоком В, который то же самое время может удалить память из кучи потока А. То есть необходимо входить в критическую секцию при каждой операции с кучей, не зависимо своя она или чужая. RS>Я не спорю, что при заведении нескольких куч в большей части случаев синхронизация эта обойдётся дёшево ибо критическая секция будет свободна. RS>Но поскольку синхронизация нужна,то получается что знать чья куча совсем не надо. Удаление памяти из своей и из чужой кучи должно выглядеть абсолютно одинаково.
Ну да. Я согласен, что вход в критическую секцию (при их использовании) будет происходить при каждой операции. И действительно, знать, какому потоку какая куча принадлежит на момент удаления не обязательно (при выделении памяти это знать нужно, чтобы определить, откуда память взять). Поэтому, я в Вашем всказывании не вижу никаких противоречий моим утверждениям...
... << RSDN@Home 1.2.0 alpha rev. 651>>
Re[12]: Перегрузка new/delete, хранение "метки" для выделенн
Vain wrote:
> ME>Создай несколько проекций (CreateFileMapping/shm_open). Отображай их > ME>(MapViewOfVileEx/mmap) поочередно на один и тот же виртуальный адрес. > С PAE не > ME>работал, но там похожие вызовы. > А, так ты имеешь ввиду свой менеджер написать?
Не совсем понимаю, что ты имееешь ввиду под менеджер. Речь шла об аллокаторе для
многопоточного приложения, или я что-то упускаю?
> Я так понял что этот > кусок пямяти должен обязательно быть Locked в на физическую память иначе > будет двойной свап (сначала винды, а потом через мой менеджер)?
Память, которую аллокатор распределяет для приложению, аллокатор получает от ОС
стандартными средствами (sbrk/mmap/CreateFileMapping/whatever-your-os-provides).
-- Maxim Yegorushkin
No Microsoft product was used in any way to write or send this text.
If you use a Microsoft product to read it, you're doing so at your own risk
Posted via RSDN NNTP Server 2.0
Re[13]: Перегрузка new/delete, хранение "метки" для выделенн
Здравствуйте, MaximE, Вы писали:
ME>Не совсем понимаю, что ты имееешь ввиду под менеджер. Речь шла об аллокаторе для ME>многопоточного приложения, или я что-то упускаю?
Ну менеджер и аллокатор — синонимы в данном контексе (поправьте кто-нибудь, если я неправ).
... << RSDN@Home 1.2.0 alpha rev. 651>>
Re[5]: Перегрузка new/delete, хранение "метки" для выделенно
Здравствуйте, SeninAndrew, Вы писали:
SA>Здравствуйте, Risk Server, Вы писали:
SA>Ну да. Я согласен, что вход в критическую секцию (при их использовании) будет происходить при каждой операции. И действительно, знать, какому потоку какая куча принадлежит на момент удаления не обязательно (при выделении памяти это знать нужно, чтобы определить, откуда память взять). Поэтому, я в Вашем всказывании не вижу никаких противоречий моим утверждениям...
Вы же сами писали, что при выделении и так понятно из какой кучи бать (по идентификатору потока кучу найти можно). Зачем тогда в самом блоке памяти хранить метку какой куче он принадлежит? При удалении эта метка не нужна. При выделении, ясное дело, тоже
Re[6]: Перегрузка new/delete, хранение "метки" для выделенно
Здравствуйте, Risk Server, Вы писали:
SA>>знать, какому потоку какая куча принадлежит на момент удаления не обязательно (при выделении памяти это знать нужно, чтобы определить, откуда память взять). RS>Вы же сами писали, что при выделении и так понятно из какой кучи бать (по идентификатору потока кучу найти можно). Зачем тогда в самом блоке памяти хранить метку какой куче он принадлежит? При удалении эта метка не нужна. При выделении, ясное дело, тоже
Нет, Вы неправильно поняли мое прошлое сообщение. Я имел ввиду, что при удалении необязательно по индексу кучи, который хранится перед выделенной памятью, восстанавливать идентификатор потока, который память выделил. Однако сам индекс кучи необходим, потому что в функцию HeapFree необходимо передать описатель кучи, из которой память была выделена.
Если мы не знаем индекс кучи (а значит и описатель), то нам нечего передать первым параметром в HeapFree:
BOOL HeapFree(
HANDLE hHeap, // handle to the heap
DWORD dwFlags, // heap freeing flags
LPVOID lpMem // pointer to the memory to free
);
... << RSDN@Home 1.2.0 alpha rev. 651>>
Re[7]: Перегрузка new/delete, хранение "метки" для выделенно
...
