Threading, separate GUI and worker stuf

[P51D]

Hi

I'm new to qt, so this could be a standard question.
I've a GUI to do some conficuration for a external hardware (connected over ethernet) and to display some results. The device could be initialized and then enabled for streaming (~1GBit/s). Depending on the used hardware driver I've to repaket de received data. So there would be a lot of stuff to do.

My question now is, how to share the data between the threads. The GUI contains all information for the device iniziaalization (about 30 variables, strings and double). But the worker thread has the result (1024 double each 20ms).

What is the best methid to deal with that? Mutex, signal/slot, message queue, gate keeper...
I would also be able to trigger some functions from the worker: for example if I change a value un the GUI, it has also to be changed on the device with the driver functions...

I hope my problem is clear.
Best regards,
P51D

[jefftee]

You didn't provide much detail regarding what you need to do once you receive data. The Qt networking classes operate asynchronously and if you're using the TCP/IP protocol, you may find that you don't even need a worker thread. If UDP, you'll find that you lose/miss UDP packets at high volumes, but depending on your application, that may be completely acceptable, after all UDP is designed as a connection-less protocol and doesn't guarantee delivery of packets in a certain sequence, or even at all for that matter.

Without much more detail to go on, I'd suggest that you first try use using Qt networking classes asynchronously. If that doesn't work for your app, then use Qt's signal/slot mechanism to pass data back and forth between your GUI thread (main thread) and your worker thread. By default, Qt will use queued connections, which work great when messaging between worker and main threads.

Good luck.

[anda_skoa]

Does the GUI need to do anything with the results or is the data simply processed in the background?

If you are using TCP, is the device the server side?
If yes, can it accept multiple connections? In this case you could have a control connection from the main thread and a data connection from the secondary thread.


Cheers,
_

[P51D]

I'm sorry for the less informations...

I have a software defined radio from ettus research with its own uhd dirver (so there is no need for accessing udp or tcp/ip stuff). I have simple to say start streaming, get receive buffer (limitted to 364 samples) and stop streaming. the configuration (setting gain, center frequency, bandwidth...) could be done with the uhd api.
The repaking is used to get frames of 1024 samples from the fft output on the fpga.
Along the system limitations I have to enable the streaming once and stop it at the end of the program (even if I want to save the received data in the future). The GUI has some inputs for defining gain, center frequency, bandwidth, ip address... and 2 grafic plots: one for the spectrum and one as waterfall. So the gui has only to display the result (fft spectrum) and to define/show the SDR properties.

So the communication direction from GUI to worker would be:
- Center frequency
- Gain
- Address
- Bandwidth
...

From the worker to the GUI there would be 1024 samples from the fft spectrum.

At the end it should look like a spectrum analyzer.

Best regards
P51D