c++ Expiring map entries thread vs event-loop - c++

Question

I am looking for some advice on a c++ design issue I am having. Some background on the issue...
I have Runnable class as shown bellow:
class Runnable
{
public:
Runnable();
virtual ~Runnable();
void Stop();
void Start();
Runnable(Runnable const&) = delete;
Runnable& operator =(Runnable const&) = delete;
protected:
virtual void Run() = 0;
// main thread function.
std::atomic<bool> mStop;
private:
static void StaticRun(void *);
std::thread mThread;
};
Then I have an ExpirationMap that inherits the Runnable class as shown below:
class ExpirationMap : Runnable
{
public:
explicit ExpirationMap();
virtual ~ExpirationMap();
void Init(uint8_t);
void Run() override;
virtual void DoExpire(uint8_t) = 0;
// Expiry function to be implemented by the derived classes.
private:
uint8_t mDelay;
};
I have a third class that inherits the ExpirationMap class. This class encapsulates std::unorderd_map.
template
class MyMap : public ExpirationMap
{
public:
void DoExpire(uint8_t) override;
void Init(uint8_t);
void Add(const KeyType, const ValueType&);
ValueType Get(const KeyType);
bool Exists(const KeyType);
ValueType Remove(const KeyType);
void Clear();
...
private:
std::unordered_map<KeyType, ValueType> mMap;
std::shared_ptr<boost::shared_mutex> mLock;
};
MyMap::Init kicks off ExpirationMap::Init which spawns off a thread with MyMap::DoExpire as the thread function. The MyMap::DoExpire is basically a never ending while loop. The basic job of the thread is to scans elements of MyMap and remove the expired entries. Each element (value) of the map has an expiration time which is used to check if an element is a candidate for expiry. All of this is implemented and is working well.
Sorry for the long intro but now on to the real problem.
Now, I have a situation where I have to port this code to an event-loop based platform. Since event-loop system supports timers with callbacks, I could pass in the DoExpire function as the callback to timer function. However, I am trying to see if there is a better way to refactor the code so that the code works on both the platforms i.e. thread based (what I have now) and event-loop based while minimizing the duplication. When creating MyMap, I want to be able to say: create a map that uses thread based expiry or timer+callback based expiry. Any suggestions or advice is greatly appreciated. Thanks.

Answer 1

I think you can do better than either approach -- you can make it so that you do not need to periodically do anything at all, and thus you won't need either event loops or an update-thread.
Since every entry in your map already has an expiration-time associated with it, all you need to do is build an API layer around the map object that pretends the expired object is no longer there, e.g. (pseudocode):
bool ExpirationMap :: Exists(const KeyType & key) const
{
if (mMap.has_key(key) == false) return false;
return (mMap[key].mExpirationTime < now); // expired entries don't count!
}
ValueType ExpirationMap :: Get(const KeyType & key) const
{
return Exists(key) ? mMap[key] : ValueType();
}
This is sufficient to get the behavior you want; the only remaining issue (which may or may not be an actual problem depending on your use case) is that the map might become large over time, full of useless old/expired entries. That can be handled various ways (including just ignoring the problem, if memory usage turns out not to be an issue, or removing an entry only when it is looked up and found to be expired), but one close-to-optimal way to handle it would be to keep a second internal data structure (e.g. a std::priority_queue that holds the entries sorted by expiration-time); then any time any method is called, you can do something like:
while(mEntriesByExpirationTime.size() > 0)
{
const ByTimeEntry & firstEntry = mEntriesByExpirationTime.begin();
if (firstEntry.mExpirationTime < now)
{
mMap.erase(firstEntry.mKey);
mEntriesByExpirationTime.pop();
}
else break;
}
... Since the entries in this priority_queue are held in expiration-time order, this call is as inexpensive as it can be since it will never iterate over more than just the expired entries that ought to be removed right now.
A design that doesn't require your program to wake up at regular intervals is generally preferable over one that does, particularly on power-constrained platforms like laptops and phones. The CPU can't sleep efficiently if your program keeps demanding to be woken up every so often :)