Исправление a--, (текущая версия) :
Список массивов (list of chunks) тут тоже не имеет особого смысла, так как этот список практически никогда не читается. А вставка и удаления в/из него интенсивные.
1. Если LRU у нас крутит одна нить, то как раз list of chunks у нас будет быстрее и с (почти?) не худшей латентностью, чем double linked list или linked list (при условии что размер чанков равен строке кэша).
2. Если мы хотим делать все это растоугодно, то вместо list of chunks можно взять Btree of chunks; тут варианты:
2А. считать, что, хотя внутри Btree unsafe, но оно все равно правильное (такое в принципе возможно, например при формальном доказательстве)
2Б. сделать растоугодное Btree исключительно на владеющих ссылках и без unsafe
Исходная версия a--, :
Список массивов (list of chunks) тут тоже не имеет особого смысла, так как этот список практически никогда не читается. А вставка и удаления в/из него интенсивные.
1. Если LRU у нас крутит одна нить, то как раз list of chunks у нас будет быстрее и с (почти?) не худшей латентностью, чем double linked list или linked list (при условии что размер чанков равен строке кэша).
2. Если мы хотим делать все это растоугодно, то вместо list of chunks взять Btree of chunks, считая, что
2А. хотя внутри Btree ансейф, но оно все равно правильное
2Б. сделать растоугодное Btree исключительно на владеющих ссылках