Looking for advice on QSharedMemory and threading
-
So I am setting out on a project to emulate multiple embedded software applications on a normal desktop PC to help with debugging the application specific code and get some early qualification of the functionality before deploying to the hardware for my company. Our end goal is also to have these emulated applications to interact with one another, so I'm trying to plan early in the design https://speedtest.vet/ https://vidmate.bid/ process to make this happen. I want each embedded application to be its own process and was thinking of having them communicate with one another using QSharedMemory.
I don't have much experience with threading as well and need a little advice on how I should structure the threads that interact with the shared memory regions. So my question is if I have one emulated application interacting with 5 other applications that have bi-directional should I set up a QSharedMemory object for each direction between each app? So that would be 10 shared memory regions, 2 for each interface between the one app and it's interfacing app. If that's the case should I also dedicate a thread to each interface or should I have a two threads, one for reading all the shared memory regions and one for writing to all the shared memory regions? Also does QSharedMemory provide a mechanism to timeout if the thread wasn't able to acquire a lock after X attempts? I would like a feature like that in order to not delay getting data from other regions in case I put reading all shared memory regions in one thread.
-
Hi and welcome to devnet,
How are these deployed embedded softwares supposed to communicate with each other ?
-
The purpose of shared memory IPC is the have one shared region and govern who controls it via a semaphore/mutex. multiple regions quickly becomes too complicated to manage. define the substance of the communications between the apps FIRST, then decide on what type of IPC you should use. Don't commit to a technology and then try to justify its use.