Jak autor v zaveru spravne podotyka, je nutne uvedomovat si rezii alokatoru na udrzovani struktur heapu - pro casto alokovane male struktury pak muze byt vhodne pouzit nejaky vlastni alokacni mechanismus. Specialne pokud struktura vyzaduje nejakou inicializaci a destrukci, je vyhodne nejaky takovy mechanismus pouzit - tato situace je typicka pro OOP (proto jak tu nekdo poznamenal se uzivaji treba pooly objektu).
Jistou vyhradu bych mel k poznamce, at se nebojime malloc volat casto. V jednothreadovem programu volani malloc bude skutecne temer zanedbatelne. Pravda to uz nemusi byt v multithreadovem programu. Vsak pro multithreadove (a specialne pro multiprocesorove) nasazeni existuji i specialni alokatory, ktere se snazi eliminovat cekani na zamku alokatoru - to by mozna mohl byt namet na nektere z pokrocilejsich pokracovani tohoto clanku.
Na single procesoru cekani na zamku absolutne nevadi- pokud je heap locknut, znamena to ze nektery jiny thread alokuje pamet a je tudiz runnable takze se akorat prohodej thready. Jo 99.99% systemu je single-cpu.
Pravda je, ze nejvetsi problem nastane na multiprocesoru - proto rikam "ze to problem byt nemusi". Nicmene i na singleprocesoru to muze znamenat urcite neprijemnosti (kdyz ne nutne problemy) - napr. v pripade, ze jedno z takovych vlaken musi z nejakych duvodu pracovat rychle (napr. zpracovava vstup, ktery nemuze moc cekat, nastavi si vyssi prioritu) a nektera jina vlakna maji nizke priority, muze vznikat v kriticke sekci alokatoru priority inversion. A to se zrovna v takovemto pripade, kdy pamet proste je treba naalokovat, obchazi blbe.
A jeste k zamykani - ani zamceni zamku pochopitelne neni zadarmo, zvlast neuspesny pokus, ktery konciva volanim kernelu (zalezi pochopitelne na implementaci zamku i vlaken).
