Sample for Mutithreading

[HugoHiasl]

Hi,

I try to implement a kind of datalogger to read the data from the inverters of my solar plant. The communication is done be serial port.

I decided to make it multithreaded. I'm a C# and Java professional but C++ is driving me crazy :-(

I stuck in a very simple problem. I want to create an overall handling object that will be part of the main program. It shall handle 1 database thread and multiple (number not fixed) threads for serial port handling. The serial threads shall emit signals to enqueue their data into a queue which will be written to a SQLITE database by the database thread.

How is the best structure to manage the running serial threads? I tried

private:
QVector<SerialThread> _serialThreads;

While building the solution it tells on a _serials.resize(1) line, that QObject::QObject(&QObject) is private

I have no clue how to handle these threads in the best way.

Any help will be appreciated.

Thanks in advance
HugoHiasl

[Lesiok]

Changing to :

QVector<*SerialThread> _serialThreads;

[tbscope]

and multiple (number not fixed) threads for serial port handling.

How many serial ports are you reading from?
If the answer is one, you are now professionally shooting your foot, your other one and your head off.

Keep it simple

[HugoHiasl]

How many serial ports are you reading from?
If the answer is one, you are now professionally shooting your foot, your other one and your head off.

Keep it simple

The micro2440 board has 3 serials on boards and it has multiple USB-Ports which could be used with a converter. I think the minimal / normal usage is reading from 1 port. But for my solar plant there are 2 different manufacturers of inverters with different protocols. So I need at least 2 different threads for serial reading.

[HugoHiasl]

Changing to :

QVector<*SerialThread> _serialThreads;

This leads to a build error: '*' cannot appear in constant expression


This is my main handling object header:


#ifndef YADLOBJECT_H
#define YADLOBJECT_H

#include <QObject>
#include <QVector>
#include "Serial/serialthread.h"
#include "Database/dbthread.h"

class YADLObject : public QObject
{
Q_OBJECT
public:
YADLObject();
~YADLObject();

private:
QVector<*SerialThread> _serialThreads;

DBThread _dbThread;

public slots:
void initialize();
};

#endif // YADLOBJECT_H

[tbscope]

That was a typo by Lesiok

SerialThread*

[wysota]

So I need at least 2 different threads for serial reading.
No, you don't. You only need one thread. If you use two, you are entering the "shoot yourself in the foot" world. Unless of course you need real concurrency when reading the ports but I'm almost sure you don't.

[HugoHiasl]

No, you don't. You only need one thread. If you use two, you are entering the "shoot yourself in the foot" world. Unless of course you need real concurrency when reading the ports but I'm almost sure you don't.

First of all thanks for the tip with the QVector. This worked for me :-)

What you are telling is an interesting point. I thought using multiple threads would be easier and necessary because the handling of the different manufacturers on the different ports is really completely different. The first one has a RS485 protokoll that must be parsed by myself. I also need to lock the communiaction on this serial port until I got response for my query. The other manufacturer delivers a shared object with an API to query the data with. Here I do not have any direct influence how long the communication on this serial port is blocked and if probably the thread is blocked too.

Others setups might have RS485 protocol with polling on serial port 1 and RS232 protocol with getting every 10 seconds data automatically pushed by the inverter on serial port 2.

To be open for those other setups I thought it would be less complicated to handle it in single threads per port. But probably your right and I should use only one and write an handling object for every port and call them sequentially in a loop to query the data from the ports.

I need to think about it.

[wysota]

If all communication with the port is done asynchronously then you only need one thread for everything. You don't need to loop over ports all the time to query them for data, both serial port implementations for Qt should provide the readyRead() signal for the serial device so you will get notified when there is anything to read.

[HugoHiasl]

Hmm.... thanks for this really interesting approach. I will do some tests with a single thread environment.

Actually I stuck in another problem. As mentioned earlier I'm really familiar with C# and Java. But I'm completely new to QT. I plan to create a BaseClass for the handlers for different manufacturers.

I planned to make a base class that defines the set of methods that will be called by the serial thread. First I tried to make an Interface but I didn't manage it The implementation classes shall emit Signals to be able to connect them to the database thread.

Now I'm trying it with a BaseClass which I want to subclass. But even with my 10 line trial I stuck in linker warnings.

This is the implmentation now:

serialhandlerbase.h


#ifndef SERIALHANDLERBASE_H
#define SERIALHANDLERBASE_H

#include <QObject>

class SerialHandlerBase : public QObject
{
Q_OBJECT
public:
SerialHandlerBase();
virtual void startHandling();
virtual void stopHandling();
};

#endif // SERIALHANDLERBASE_H


serialbasehandler.cpp


#include "serialhandlerbase.h"

SerialHandlerBase::SerialHandlerBase()
{
}


The compiler says: undefined reference to 'vtable for SerialHandlerBase'
and the linker: collect2: Id returned 1 exit status

I can get rid of the compiler messages if I declare a destructor and implement it in the cpp file. But it does not fix the linker message.

Do you have an idea for me?

[wysota]

If you don't want to implement the virtual methods in the class (making it an interface or a pure abstract class as we call it in C++), you need to tell that to the compiler:

#ifndef SERIALHANDLERBASE_H
#define SERIALHANDLERBASE_H

#include <QObject>

class SerialHandlerBase : public QObject
{
Q_OBJECT
public:
SerialHandlerBase();
virtual void startHandling() = 0;
virtual void stopHandling() = 0;
};

[HugoHiasl]

I tried adding these = 0 but it did not change anything


#ifndef SERIALHANDLERBASE_H
#define SERIALHANDLERBASE_H

#include <QObject>

class SerialHandlerBase : public QObject
{
Q_OBJECT
public:
SerialHandlerBase();
virtual void startHandling() = 0;
virtual void stopHandling() = 0;
};

#endif // SERIALHANDLERBASE_H

[wysota]

Did you run qmake after adding the Q_OBJECT macro to your class?

[HugoHiasl]

Did you run qmake after adding the Q_OBJECT macro to your class?

This was the reason. Perfect thanks :-)

I'll try to implement the handler class now. Am I able to set the owner thread to sleep ? I think my next question will be concerning connecting the signals of the objects of the serial thread to the slots of the object in the database thread.

But berfore asking this I'll do some trials on my own.

Thank you very much for your patience.

[wysota]

Again, you only need one thread. Not one for serial, one for database, one for something else. One in general, it's not java.

[HugoHiasl]

Again, you only need one thread. Not one for serial, one for database, one for something else. One in general, it's not java.

Hmm.. I seem to be too focused to my standard development environment in c# and java. I'll try to sort it out in my mind. My fear is that the task that occur sometime will interrupt the data retrieval process. From time to time the saved data needs to be sent as xml to a web page. The data needs to be displayed in the gui and so on.

I think I'll need the one or other day to get into the "best practices" for QT.

[wysota]

Nothing will interrupt anything and you won't have problems with synchronizing all the threads. Just start thinking in asynchronous manner.

[jimc1200]

Nothing will interrupt anything and you won't have problems with synchronizing all the threads. Just start thinking in asynchronous manner.

@wysota:

this is interesting as i'm also looking into implementing threaded architecture. from what you are suggesting single thread with asynchronous handling will do the job. but isn't it much more efficient if multiple threads are involved? let's take for an example a method(slot) handling the signal in a single thread, wouldn't that stop or delay other processing as compared to concurrent processing in multithreads?
i'm still quite undecided whether to implement asynchronous handling in one thread or implement multiple threads. would really appreciate your expert advice as to which one is more efficient. thanks.

[squidge]

It seems that your threads will be mostly I/O bound - ie, they will spend most of there time waiting for an i/o event to complete, so really, it makes no sense to use them for these functions (you can of course, but it'll just use up more resources and make coding more difficult).

If you were doing something like a long computation then threads would indeed make sense, but your serial routines definitely do not need threads, and your database thread is questionable too (ie, you would have to be doing some heavy processing over millions of rows and not just simple inserts or selects)

[jimc1200]

It seems that your threads will be mostly I/O bound - ie, they will spend most of there time waiting for an i/o event to complete, so really, it makes no sense to use them for these functions (you can of course, but it'll just use up more resources and make coding more difficult).

If you were doing something like a long computation then threads would indeed make sense, but your serial routines definitely do not need threads, and your database thread is questionable too (ie, you would have to be doing some heavy processing over millions of rows and not just simple inserts or selects)


Thanks fatjuicymole for your insights. I think a single thread with asynchronous handling will satisfy my requirements for now.I'll try to check if there's any considerable slow down in the IO operations and if such is the case I might start adding threads. But that would be my last resort as threading adds significant complications in the code ,more so when debugging :o