It's been a while...

I know it's been a while since I updated my blog. But I've been struggling with a couple of things, both personally as well as on my domotics.

On personal level, it's been a sad time for me. Two weeks back, my beloved Father passed away. Knowing my Mother passed away hardly 20 months before, one can imagine I've known happier times....

This is the site I created to commemorate my beloved Parents...

Anyway, life goes on and I will have to live with all the good memories I have of both my parents (and I can assure you there are many, many of them...).

Another issue I was struggling with, was the amount of threads in my system. I'm not even halfway my development, and I had already 20+ threads running.
This was too much and the reason was quite simple: every object that represented hardware that needed polling, was running in its own thread.

For instance, for my IO expanders, I had one thread per instance. This is of course very expensive and I was looking to a solution that would bring down the amount of threads to one per functionality.

So, one thread for all my IO tasks, one thread for my temperature measurements, etc...

I've been thinking hard on how to solve this and found a good solution in the usage of STL and polymorphism, using callback functions.

The only precondition was that the prototype of my callback functions all had to be the same. But that was not an issue: it perfectly fitted into one another.

The goal was to fill an array with pointers to callback functions and then scan that array at regular times (every 10ms, since I wanted to have a granularity of 10ms to poll my IO pins).

Registering the callback functions happens in the class that maintains a thread. That thread is running every 10ms and completely scans the array (I used a vector array for that). The callback function was called every 10ms and inside the callback function, a decision was taken if a certain pin of a certain IO expander had to be checked or not (depending on the polling time that was set for that particular pin).

So, I first started by creating a virtual class with only one function: class CSubThread().

#include "iostream"
using std::cout;
using std::endl;

class CSubThread
{
public:
     virtual void RunOnce( void )
     {
         cout << " I ran once... " << endl;
     };
};

Note: "iostream" should in fact be in between left and right triangle characters, but Blogger has problems printing those characters.  It thinks it's an HTML ta issue...

CSubThread() has one function, RunOnce(), that does not take any parameter and also doesn't return anything. You can't have something simpler, I guess...

The purpose is now that other classes will inherit the class CSubThread() and implement the function RunOnce().

The classes that need the polling mechanism, will implement RunOnce() as follows:

void C8575Io::RunOnce( void )
{
    Execute();
}   /* RunOnce */

Since RunOnce() is declared virtual in the base class, other classes can redefine the content of the function according their own needs.

In the above example, RunOnce()--which is a public member of the class C8575Io()-- simply calls a private class Execute() which will do the necessary things to poll the corresponding IO expander.

As you can see, very simple... The public function RunOnce() is simply calling a private function Execute(), which will see if one or more pins of a IO expander has to be polled or not.

How is the function RunOnce() connected to the callback array?

As said before, I wanted to have one thread per "activity", so, one thread for the IO polling, one thread for the temperature polling etc...

The first thing the class C8575Io() must do, is connecting to the IO thread. Now, there are two situations:

1. The thread for the IO polling is already there
2. The thread for the IO polling still has to be created.

This is not the concern of the class C8575IO(). This class simply does a call to the message queue class using the following command:

pMsgQueue = CMqMgr::QueueInstance();