Sample for Mutithreading

[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

#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

To copy to clipboard, switch view to plain text mode 

[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