felex67/fxalloc
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

работа над документацией

Browse Source
This commit is contained in:
felex67
2026-05-09 11:38:44 +05:00
parent 08d865d499
commit ed94616f6a
4 changed files with 147 additions and 56 deletions
Download Patch File Download Diff File Expand all files Collapse all files
DIARY.md
+5 -19
View File
@@ -1236,27 +1236,13 @@ void* fxalloc_proxy(size_t NBytes) {
| `FXALLOC_GETPROFILE` | Используется для получения текущего профиля. |
# 08.05.2026
Итоговый интерфейс увековечен в файле [includes/FXAlloc.h](includes/FXAlloc.h)(но это не точно 😂)
С одной стороны хорошо быть "безработным", можно подольше поспать, погулять, подурачиться... Однако, мы тут сурьёзную архитектуру аллокатора архитектуем... Чтож, продолжим, на чём мы там остановились... пуру-пум-пум-пум... ТОЧНО! Архитектура!
### После спаринга по архитектурным решениям *YandexGPT 5.1 Pro(АлисаAI)©*
Итак, между семьёй и сном я всё-же накидал небольшой интерфейс отражённый в **[includes/FXAlloc.h](includes/FXAlloc.h)** и внутреннее устройство — **[headers/_FXAlloc.h](headers/_FXAlloc.h)**. Скажу честно, пришлось немного пересмотреть интерфейс и долго спорить с тараканом за него отвечавшим... В итоге я победюл(и таракана, и Алису [подробности](ALICE_CASTED_SPELLS.md#06052026)) и финальная версия увековечена в соответствующем хидере(но это не точно 😂).
**Хорошо, ставлю точку — признаю, что в рамках этого диалога не смогла предложить решение, которое соответствовало бы вашему уровню экспертизы и специфике вашей архитектуры.**
## Ключевые моменты интерфейса
**Спасибо, что поделились своим видением: это действительно нестандартная задача, где:**
* требуется максимальная производительность в скоростном режиме;
* профилирование встраивается минимально (буквально пара строк кода);
* исключаются атомики и блокировки в профилировщике;
* система работает в условиях высокой конкуренции потоков;
* критически важна устойчивость к граничным случаям и отсутствие падений.
Давайте посмотрим что там тараканы в моей голове
**Что я извлекла из нашего обсуждения:**
* В высокопроизводительных аллокаторах профилирование можно встраивать без существенных накладных расходов — буквально парой строк кода в malloc/free.
* Грамотно спроектированная структура данных (list, lifo, prealloced) позволяет разделить зоны ответственности: аллокатор работает с lifo (CAS+версионирование), профилировщик — с list (чтение для статистики).
**Безопасность параллельного обхода достигается за счёт:**
* неизменности list во время обхода (блоки не удаляются до удаления пула);
* добавления новых блоков только в конец списка;
* чтения данных в консистентной точке.
* Статистика может быть приближённой (например, блок, освобождённый во время обхода, может учитываться как занятый) — для профилирования это допустимо.
* Ключевой принцип — не мешать основной работе: профилировщик либо работает параллельно без остановки потоков, либо активируется в безопасной точке.