what is best architecture to share data between front end and backend using thread ?

[Qt embedded developer]

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.

At same time if front end receive any input from user then it also need to share data using that shared memory.

What is best way to deal with this situation? what are the best architecture i can use to easily process and share data between back end and front end ?

[JonB]

@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.

[JonB]

@Qt-embedded-developer
Before people answer, are you wedded to using std::thread? My inclination would be to use Qt's QThread and related, which are set up for e.g. signals & slots.

[Qt embedded developer]

@JonB As Front end developer know the qt and qml they gone use QThread but the backend developer don't aware of it so they use std::thread

So can you suggest what's answer of my post.

[JonB]

@Qt-embedded-developer So if you have said you want to use shared memory, do so. Just be careful about locking.

[JoeCFD]

@Qt-embedded-developer You may also try C++ socket + QLocalSocket

[kshegunov]

@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.

[Qt embedded developer]

@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.

[jsulm]

@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?!

[Qt embedded developer]

@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

[jsulm]

@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.

[SamiV123]

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.

[Qt embedded developer]

@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.

[jsulm]

@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.

[JonB]

@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.

[Qt embedded developer]

@SamiV123 , @JoeCFD @JonB @jsulm

Thank you