what is best architecture to share data between front end and backend using thread ?
-
@Qt-embedded-developer You may also try C++ socket + QLocalSocket
-
@Qt-embedded-developer said in what is best architecture to share data between front end and backend using thread ?:
Hi I want to know what architecture i need to use when backend use shared memory for send data using std::thread and front end of QT and QML need to use that data to process and show on ui application.
Your question is incomplete. What do you mean by backend and what by frontend. Either can live in the same process, or be separate processes, or even on separate machines (e.g. communicate over a network). The choice of architecture is driven by the use case.
At same time if front end receive any input from user then it also need to share data using that shared memory.
Don't share memory if you can avoid it (which is most of the time). Opt to use (reentrant) value types that have clear and meaningful lifetimes.
-
@kshegunov HI Backend and front end both live in same process and same machine.
Backend do getting sensor data and related state share to front end via shared memory.
So can you answer again for this post.
-
@Qt-embedded-developer said in what is best architecture to share data between front end and backend using thread ?:
Backend and front end both live in same process and same machine
Then why do you need shared memory or any other type of IPC?!
-
@jsulm Because there are 2 team working on this same application.
BackEnd and front end will communicate with each other using request and response based communication.
For request and response we use the share Memory
-
@Qt-embedded-developer I don't get it: if backend and frontend are in SAME process (like you wrote) then why do you need shared memory? Are you sure back end and front end are in same process? It would not make sence to have both in same process.
-
Since you said "sensor data" I'm going to assume that means a set of properties that are displayed on some UI and updated at some interval.
Create 2 copies of the properties.
Background thread updates one copy while UI is showing another copy. Then you swap.
When this is coded you just have two pointers to the data sets, when the background thread is done updating one set it indicates that and the code can then swap the pointers, your UI starts displaying the latest data and the old data gets overwritten int the sensor thread with new data.
-
@jsulm though back end and front end are in same process
Back end will write logic for getting data from sensor
But it will not directly send data to gui.
Because front end work is to work only on gui side. Their responsibility is to request in some format to backend
Now back end come with idea that we have to send request using share memory
So what back end continuously monitor the share memory and when they get request they response and send updated data to share memory
So now if @jsulm you feel that there should not be use share memory.
Then what is best things to request and get response in this type of code
Do you mean i have to directly use backend implemented function to get data and show it as it get change Or something else.
For our prospects we created this share memory to communicate but any expert feel other then this something is more better then it would be great to know.
-
@Qt-embedded-developer said in what is best architecture to share data between front end and backend using thread ?:
So now if @jsulm you feel that there should not be use share memory
You know that everything in same process already shares memory? There is absolutelly no need for any kind of IPC if everything is in the same process. Really wondering why you think you need it.
-
@Qt-embedded-developer
As @jsulm has been saying, you are not cross-process so do not need shared memory or other IPC. And shared memory is for an "unstructured blob" of memory, better keeping it structured which is presumably what you start with.The two obvious ways of sharing data are:
-
Send a copy of the data between threads. This is what Qt's cross-thread signals/slots would (typically) do, but you cannot use that because you said the backend is not Qt. And of course copy is not good if both sides want to update the data.
-
Use mutexes, Qt's
QMutex, to actually share the data. Careful lock/unlock to ensure synchronous access across threads. This does allow the data to be shared in either direction, with updates.
If it suits your situation there is also @SamiV123's suggestion of maintaining a pair of data structures which front & backend swap between. Ultimately (without signals) that will still probably use a mutex to indicate when to swap.
-
-
-
Q Qt embedded developer has marked this topic as solved on
