Handling Database on Multiple Thread
-
Using a QThread for a single insert statement doesn't look very effective. The same goes for the serial communication - QSerialPort is async - no thread needed.
@Christian-Ehrlicher There are multiple insert statements and I am using open close principal for database connection.
Regarding Serialport Qt serial blocking example
I referred this blocking example and I read and write data from serial thread and also planning to use wait conditions. -
delay logic is troublesome because it makes assumptions about response times, sometimes needlessly, and other times not long enough. Avoid that kind of programming when possible, and favor event sycronization instead.
-
delay logic is troublesome because it makes assumptions about response times, sometimes needlessly, and other times not long enough. Avoid that kind of programming when possible, and favor event sycronization instead.
@Kent-Dorfman For serial communication most preferable way is to use async code with signals and slots. Understood the point here.
But can you tell me when is preferred way to use above blocking example.Regarding Database connection can I use the thread where there are multiple insert statements and I’m using open close method here.
Thank you!
-
open/close is expensive. insert/select based on prepared statements is cheap. move the open/close logic out of the thread and do mutext blocked sql functions if you chose a single connect. otherwise create a connection pool and have your thread use a free connection from the pool for every concurrent sql transaction.
implementation is left as an exercise for the OP.
-
Even two or thread statements don't need a separate thread. Especially when the open/close is done in the run function as @Kent-Dorfman pointed out.
Write a proper class which opens the db in the ctor and closes it in the dtor, implement the insert statements in a slot() and after you found out that this causes performance problems (which I doubt) then move this object to another thread. -
Even two or thread statements don't need a separate thread. Especially when the open/close is done in the run function as @Kent-Dorfman pointed out.
Write a proper class which opens the db in the ctor and closes it in the dtor, implement the insert statements in a slot() and after you found out that this causes performance problems (which I doubt) then move this object to another thread.@Christian-Ehrlicher Thank you for the suggestion I will implement it and check the result.
Although before proceeding my query is since I'm reading data from serialthread and emitting it to mainscreen and in mainscreen I'm displaying the values as well as storing the values in the database using databasethread. My point here is should I use a locking mechanism here when handling the data between threads? -
open/close is expensive. insert/select based on prepared statements is cheap. move the open/close logic out of the thread and do mutext blocked sql functions if you chose a single connect. otherwise create a connection pool and have your thread use a free connection from the pool for every concurrent sql transaction.
implementation is left as an exercise for the OP.
@Kent-Dorfman I will take your suggestions as well as @Christian-Ehrlicher suggestion and implement them.
-
@Christian-Ehrlicher Thank you for the suggestion I will implement it and check the result.
Although before proceeding my query is since I'm reading data from serialthread and emitting it to mainscreen and in mainscreen I'm displaying the values as well as storing the values in the database using databasethread. My point here is should I use a locking mechanism here when handling the data between threads?@mvsri said in Handling Database on Multiple Thread:
My point here is should I use a locking mechanism here when handling the data between threads?
Don't use threads and you don't need a locking.
Use signals and slots properly and you don't need a locking even between threads. -
@mvsri said in Handling Database on Multiple Thread:
My point here is should I use a locking mechanism here when handling the data between threads?
Don't use threads and you don't need a locking.
Use signals and slots properly and you don't need a locking even between threads.@Christian-Ehrlicher I rewrote the code and implemented everything with signals and slots, thank you for the suggestions. It pretty much sums up the questions I had.
I just need one suggestion though what is the real use case of blocking serial communication method Qt serial blocking example. When do we use such kind of code then?
-
@Christian-Ehrlicher I rewrote the code and implemented everything with signals and slots, thank you for the suggestions. It pretty much sums up the questions I had.
I just need one suggestion though what is the real use case of blocking serial communication method Qt serial blocking example. When do we use such kind of code then?
@mvsri said in Handling Database on Multiple Thread:
When do we use such kind of code then?
I would say - mostly never. Maybe if there is really much data coming in from the serial port (e.g. in high-speed modes when you can get ~8MBit/s) to make sure all the data can be handled without killing the gui interaction. But as I said earlier - don't use threads until you really need them :)
-
to continue the point @Christian-Ehrlicher mentioned above, blocking serial tasks usually exist on server daemon applications, but not on anything with user interaction or a GUI.
