caching - How to LRU-cache numerous objects made of C++ STL heavy structures? -

i have big c++/stl data structures (mystructtype) imbricated lists , maps. have many objects of type want lru-cache key. can reload objects disk when needed. moreover, has shared in multiprocessing high performance application running on bsd plateform.

i can see several solutions:

1. i can consider life-time sorted list of pair<size_t lifetime, mystructtype v> plus map o(1) access index of desired object in list key, can use shm , mmap store everything, , lock manage access (cf here).
2. i can use redis server configured lru, , redesign data structures redis key/value , key/lists pairs.
3. i can use redis server configured lru, , serialise data structures (mystructtype) have simple key/value manage redis.

there may other solutions of course. how that, or better, how have done that, keeping in mind high performance ?

in addition, avoid heavy dependencies boost.

i built caches (not lru) recently.

options 2 , 3 quite not faster re-reading disk. that's no cache @ all. also, far heavier dependency boost.

option 1 can challenging. instance, suggest "a lock". quite contended lock, must protect each , every lifetime update, plus lru operations. since objects heavy, may worthwhile have unique lock per object. there intermediate variants of solution, there more 1 lock, more 1 object per lock. (you still need key protect whole map, that's replacement only)

you can consider if need strict lru. strategy assumes chances of object being reused decreases on time. if that's not true, random replacement good. can consider evicting more 1 element @ time. 1 of challenges when element needs removing, threads, it's sufficient if 1 thread removes it. that's why batch removal helps: if thread tries take lock batch removal , fails, can continue under assumption cache have free space soon.

one quick win not update lru time of last used element. newest, making newer won't help. of course has effect if use element again, (as noted above) otherwise you'd use random eviction.