Need guidance on design of running multiple instances of an executable

[kerplatz]

I think I have a problem that has become unmanageable in my current configuration. Let me give some background.

Originally my application was only going to have to run one instance while sending and receiving data via an USB to I2C connection to 3 different boards. This all works well and is easily done on one PC using just about 20% of the CPU while it is gathering data. Then I get a request to add a bunch of functionality to the program. First was a TCP server that would handle communications with LabView drivers. This add-on did not seem to cause much slowdown when being used and none if no LV drivers were connected. I have a significant amount of things going on in the GUI, such as a graph, table and a few strip charts. Not all of these are being used at the same time, but they are present.

So now I have been tasked to have up to 8 instances of my programming running at one time all on the same computer. This actually works, but it pegs the CPU utilization at 100% while all of these are running which is not so great. I can think of a couple of ways to maybe take the strain away from the CPU, but neither is good since they would likely take a significant time to rewrite the code. One is to have all the GUI controls be on a tab for each instance and run each tab in a separate thread. But only one GUI could be seen at a time, which is not desired. Another is to compile the program as a command line app and get rid of the GUI, but again not that desirable. I suspect there may be other ideas the I have not considered, and would gladly like to hear them. Some type of sharing resources by CVI would be great, if that is possible,

The other thing that these instances need to do is be able to communicate with each other. I had originally wanted to use UDP, but could not get it to work, so I am using named pipes instead. In order for these 8 programs to communicate, I created another app that then created the named pipe and I now have that working pretty good when all 8 instances are running. It is basically a control panel that lets you control all 8 instances at the same time via named pipes and have an abbreviated view of each status of the main executable. Again, this is all working pretty good and is doing what I want, but the CPU is still at 100% since I have not reduced the load on the CPU.

So if you have followed me this far, there is one more twist and where everything kind of falls apart. Now the powers that be want a TCP connection on the other side of this control panel so it can be controlled remotely. It basically replicates the controls on the control panel, and it suffers from many problems that I can't seem to get under control. I think the communications chain is just to long and complicated at this point.

If you followed all that, I am hoping that someone might know how to get the resource problem under control, have a better way of doing the sharing of data using Windows Inter Process Communications, or know of a better architecture model (PS - I don't seem to have a data collection problem), or something I have not even considered.

Please ask questions if you want me to clarify something. Thanks.

[gdargaud]

Let me see if I got this straight. You have:

- 3 USB hardware devices which communicate with...

- 8 instances of the same program (each having their own UIR) which themselves have their own TCP server so they can be controled by...

- a final client program which should have its own copy of any of the remote UIR

Is that it ? First, since your 8 progs need to communicate between them, why don't you run only one process with 8 threads ? It should be significantly easier on the processor and easier on the data sharing part (global vars with locks, whatever). And have the main thread handle all the UIR needs.

Also I don't understand this need to to have 3 hardware communicating with 8 progs at the same time. I don't see how this could work. How did you write the communication driver ? Since you talk about pipes, does it run on Linux ? (I'm not aware of pipes on Windows).

[kerplatz]

You got most of it correct. Here is another attempt to describe the communications. I have 3 boards with which I communicate via a USB to I2C connection. The application sends the data via USB to a FTDI chip that translates it into I2C and then on to each of the boards. I talk to each board via the one FTDI chip. But here is what you really missed. each instance of the app communicates with a set of 3 boards.

The rest of the confusion can be cleared up by saying yes Windows has named pipes. It is part of Windows Interprocess Communications and this may not be the best tool to use. I use this to aggregate the data from the 8 instances of the application into a single data point that then is sent via TCP to a third party client in a web browser.

I hope that clears that up. I know this is overly complicated, but I had to adapt what I had to make this work. I know the architecture is all wrong, that is why I am asking. Or at least a way to use less resources. Thanks.

[gdargaud]

My take on this would be to have a single process on the PC to communicate with all the cards, not 3. This way you can better prioritize and control what is going on. Then dispatch the data to whoever wants it via your preferred communication method. Make that first program multithreaded if need be, but keep it as simple as possible (no user interface, pure C, no CVI). Then do whatever you want in the other programs that receive the data from it (save, display, control/command...). If you need to save everything that comes from the card in files, you can do so in the 1st prog.