Реализация пула памяти

Question

Я хочу создать диспетчер пула памяти для проекта встроенной системы. Я хочу сделать отдельный заголовок и соответствующую реализацию в файле .c (скажем, mempool.c). Мое сомнение здесь в том, что когда я вызываю malloc() в реализациях функций в этом файле, какую память кучи я использую?

Учитывая, что есть другие файлы (скажем, foo1.c и foo2.c), которые используют заголовок «mempool.h» и соответствующие функции в mempool.c. Итак, когда я компилирую и выполняю foo1.c и foo2.c одновременно, будут ли их вызовы к функциям в mempool вызывать выделения на 2 полностью отдельных кучах или один и тот же?

Answer 1

Есть три C исходных файлов в игре: mempool, foo1, foo2.

.h файл (ов) header файлы, описывающие функции, которые выглядят как "и как их следует называть.

При компиляции либо foo1 или foo2, объект-код из mempool.o будет статически в них.

Сделав это, они теперь представляют собой «две совершенно отдельные программы», каждая из которых содержит идентичный бит объектного кода.

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

Если вы используете do, хотите, чтобы программы фактически «обменивались памятью», вы должны использовать именованный раздел общей памяти. (shmget и т. Д.), и вы должны создать свой менеджер менеджера пула памяти, чтобы находить, открывать и правильно использовать этот общий ресурс. Еще раз, обе программы будут содержать свою собственную независимую копию объектного кода вашего менеджера пула памяти.

(Подсказка:. «это уже сделано» Вы можете найти полные библиотеки, которые делают это, на таких местах, как GitHub, вместо того, чтобы приступать к заказному реализации себя)

=== Дополнительное примечание:

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

При использовании этого подхода объект-код загружается приложением во время выполнения, а он не становится «частью» объектного кода приложений, которые его используют. Вместо этого он становится доступным для них. Кроме того, операционная система знает об обмене, и может признать недействительным экземпляр, который совместно используется. Он может разрешить общий набор распределений памяти быть «принадлежащим» тому одиночному, совместно используемому экземпляру. Операционные системы (и версии, «исторические против современных» , например MS-Windows ...) различаются в зависимости от конкретной точки.