Thread that read from QSerialPort

rileo8

Ok perfect,thanks to everybody for the help!
Now i better understand Qthreads...

JKSH

You're welcome.

Good luck with your project!

rileo8

Hi, i'm stille here with another question..

now my code loooks like this:

@#include "mainwindow.h"
#include <QtGui/QApplication>
#include <QThread>

#include "executer.h"
#include "checker.h"
#include "networker.h"

int main(int argc, char *argv[])
{
QApplication a(argc, argv);
MainWindow w;
w.showMaximized();

Checker checker;
Networker networker;
Executer executer;

QThread checkerThread;
QThread networkerThread;
QThread executerThread;

QObject::connect(&executerThread,SIGNAL(started()),&executer,SLOT(Start()));

checker.moveToThread(&checkerThread);
networker.moveToThread(&networkerThread);
executer.moveToThread(&executerThread);

checkerThread.start();
networkerThread.start();
executerThread.start();

int returnValue=a.exec();

executerThread.wait();

return returnValue;

}
@

i neew to share an object (of a custom Configuration type) between all trheads.

Is it coorect to declare it in the main, pass it to all htreads and also share a mutex so that every thread lock and unlock it?

Thanks

JKSH

If it is not a QObject, then yes you can do that.

If it is a QObject, then you are not allowed to share it between threads. QObject is not thread-safe.

See this page for info on how to share data between threads: http://doc-snapshot.qt-project.org/qt5-stable/threads-synchronizing.html

t3685

[quote author="JKSH" date="1383215991"][quote author="rileo8" date="1383208867"]that enters the event loop and waits until exit() is calle

Is it correct?[/quote]Yes, it's correct :)

Next, read the "Thread Affinity" section of the "QObject documentation":http://doc-snapshot.qt-project.org/qt5-stable/qobject.html#thread-affinity -- it explains how to choose the thread to run your slots.

[quote author="t3685" date="1383215445"]No it is not correct. You don't need a wait loop like that.[/quote]rileo8 realized that after reading the documentation. That's why he asked if it's correct to replace the wait loop with exec().[/quote]

The QSerialPort class is asynchronous. You don't need threads to do this.

rileo8

It is not a QObject, is a simple c++ custom class

JKSH

[quote author="t3685" date="1383225223"]The QSerialPort class is asynchronous. You don't need threads to do this.[/quote]Yes, if I/O is slow enough, then no threads are needed. That's why I asked about the read/write rate.

rileo8

Yes i understood this,
infact now i have:

GUI thread
thread for operations on serialport 1
thread for operations on serialport 2
thread for network operations

Now i also added a custom Configuration class that is share d between threads with a shared QMutex to enable access to it

t3685

[quote author="JKSH" date="1383225543"][quote author="t3685" date="1383225223"]The QSerialPort class is asynchronous. You don't need threads to do this.[/quote]Yes, if I/O is slow enough, then no threads are needed. That's why I asked about the read/write rate.[/quote]

The write function returns immediately. The readyRead() signal is only emitted when data is available. I don't think it matters then what the Baud rate is.

http://qt-project.org/doc/qt-5.1/qtserialport/terminal.html

JKSH

[quote author="t3685" date="1383225815"]
The write function returns immediately. The readyRead() signal is only emitted when data is available. I don't think it matters then what the Baud rate is.[/quote]Sorry for being unclear; I meant the rate at which read() and write() need to be called (relative to other operations). An active thread will experience jitter, especially on a non-real-time OS. That raises the possibility of a buffer becoming empty. Depending on how the devices have been designed, an empty write buffer could kill the entire connection.

t3685 has a very valid point though. rileo8, try running your workers in the main thread first using the asynchronous API, and see how your program performs. You might not need 3 extra threads.

rileo8

Hi,

my point is that i need to accomplish different operations on 2 serial ports and also network operations so i think that putting all i t he gui can cause gui freezing...

kuzulis

Hi guys,

the main point to use QtSerialPort's objects in different thread - a bug with the stopping of I/O at moving window or expanding window. Of course, this problem only in Windows OS. :)

[quote]

GUI thread

thread for operations on serialport 1

thread for operations on serialport 2

thread for network operations

[/quote]

IMHO, it is better:

GUI thread
thread for operations on serialport 1, serialport 2, network