Question

I am trying to implement LRU Cache using C++ . I would like to know what is the best design for implementing them. I know LRU should provide find(), add an element and remove an element. The remove should remove the LRU element. what is the best ADTs to implement this
For ex: If I use a map with element as value and time counter as key I can search in O(logn) time, Inserting is O(n), deleting is O(logn).

Answer 1

One major issue with LRU caches is that there is little “const” operations, most will change the underlying representation (if only because they bump the element accessed).

This is of course very inconvenient, because it means it’s not a traditional STL container, and therefore any idea of exhibiting iterators is quite complicated: when the iterator is dereferenced this is an access, which should modify the list we are iterating on… oh my.

And there are the performances consideration, both in term of speed and memory consumption.

It is unfortunate, but you’ll need some way to organize your data in a queue (LRU) (with the possibility to remove elements from the middle) and this means your elements will have to be independant from one another. A std::list fits, of course, but it’s more than you need. A singly-linked list is sufficient here, since you don’t need to iterate the list backward (you just want a queue, after all).

However one major drawback of those is their poor locality of reference, if you need more speed you’ll need to provide your own custom (pool ?) allocator for the nodes, so that they are kept as close together as possible. This will also alleviate heap fragmentation somewhat.

Next, you obviously need an index structure (for the cache bit). The most natural is to turn toward a hash map. std::tr1::unordered_map, std::unordered_map or boost::unordered_map are normally good quality implementation, some should be available to you. They also allocate extra nodes for hash collision handling, you might prefer other kinds of hash maps, check out Wikipedia’s article on the subject and read about the characteristics of the various implementation technics.

Continuing, there is the (obvious) threading support. If you don’t need thread support, then it’s fine, if you do however, it’s a bit more complicated:

• As I said, there is little const operation on such a structure, thus you don’t really need to differentiate Read/Write accesses
• Internal locking is fine, but you might find that it doesn’t play nice with your uses. The issue with internal locking is that it doesn’t support the concept of “transaction” since it relinquish the lock between each call. If this is your case, transform your object into a mutex and provide a std::unique_ptr<Lock> lock() method (in debug, you can assert than the lock is taken at the entry point of each method)
• There is (in locking strategies) the issue of reentrance, ie the ability to “relock” the mutex from within the same thread, check Boost.Thread for more information about the various locks and mutexes available

Finally, there is the issue of error reporting. Since it is expected that a cache may not be able to retrieve the data you put in, I would consider using an exception “poor taste”. Consider either pointers (Value*) or Boost.Optional (boost::optional<Value&>). I would prefer Boost.Optional because its semantic is clear.