Менеджер памяти от Борланд

← →
panov (2003-05-22 10:54) [0]

Не разбирался ли кто с принципами работы BorlandMM?

Если да, то натолкните на мысль, как возможно реализовать общий менеджер памяти для основного потока и DLL.

← →
Игорь Шевченко (2003-05-22 11:21) [1]

Журнал RSDN Magazine, последний (вроде) номер за прошлый год, статья Mystic"a - довольно подробная. На сайте rsdn.ru

← →
rounin (2003-05-22 11:25) [2]

На счет принципов работы BorlandMM - в RDSN #2 2002 была статья Mystic"a.

← →
panov (2003-05-22 11:33) [3]

Спасибо.

← →
Digitman (2003-05-22 11:40) [4]

> panov

а критично ли использование в твоем случае именно borlandmm ?
если нет, то можно, к примеру, задействовать тот же менеджер от MS (в составе msvcrt.dll): мультипоточный доступ в нем предусмотрен изначально, базовые ф-ции практически совместимы c TMemoryManager - malloc(), realloc(), free() достаточно легко встраиваются в Борландовскую шаблонную структуру TMemoryManager

← →
rounin (2003-05-22 11:41) [5]

Игорь Шевченко © (22.05.03 11:21)
:)

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

← →
panov (2003-05-22 11:48) [6]

>Digitman © (22.05.03 11:40)

Как раз и не хочу использовать BorlandMM.
Да и вообще использовать другие менеджеры.

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

← →
Digitman (2003-05-22 12:18) [7]

> panov

может, и не так уж и сложно, но уж точно, что "овчинка выделки.."
я бы на твоем месте присмотрелся к msvcrt.dll

тем паче, что, к примеру, многие прогр.продукты, допускающие расширение своей функц-ти за счет подключаемых библ.модулей, требуют соглашений и умолчаний в использовании именно этого менеджера. Яркий пример - сервер InterBase (и его клоны) позволяет подключать пользовательские библ.ф-ции (UDF), в которых для возврата результата допускается аллокировать память вызовом msvcrt.malloc(). При соответствующих UDF-декларациях на стороне сервера после получения результата ядро сервера освобождает аллокированный блок вызовом msvcrt.free(). Причем вызовы ядром сервера ф-ций пользователя могут происходить (и происходят) в различных кодовых потоках одновременно, и при этом никаких конфликтов и мемликов не происходит.

← →
Иван Шихалев (2003-05-22 12:21) [8]

У меня на http://fpc.by.ru/ аналог borlandmm для FPC. С исходниками, естественно.

А вообще, опиши задачу в целом.

← →
icWasya (2003-05-22 12:38) [9]

>как возможно реализовать общий менеджер памяти для основного потока и DLL.

1)
пишется DLL (например MyMemo.DLL)
в ней реализуются как мимум три фцнкции
function MyGetMem(Size: Integer): Pointer;
function MyFreeMem(P: Pointer): Integer;
function MyReallocMem(P: Pointer; Size: Integer): Pointer;

2)
пишется юнит, который должен подключаться первым во все проекты (Exe и DLL)
в нём
2.1) проверяется наличие MyMemo.DLL
2.2) заменяется стандартный менеджер памяти на функции, взятые из MyMemo.DLL
как это делается - прсмотреть в ShareMem.Pas

собственно всё

как будут реализованы MyGetMem,MyFreeMem,MyReallocMem- дело вкуса
скорей всего в BorlandMM.DLL используется стандартный менеджер памяти

идея проста - не использовать встроеный в приложения менеджер памяти,
а использовать внешний - один на все DLL и Exe процесса.

← →
MBo (2003-05-22 12:49) [10]

http://www.optimalcode.com/memmgr.htm

← →
Anatoly Podgoretsky (2003-05-22 13:22) [11]

http://podgoretsky.com/cgi-bin/dlcounter/npscnt?file=http://podgoretsky.com/ftp/Docs/Delphi/Memory/index.html&file_id=MemMan

Менеджер памяти от Борланд Найти похожие ветки