1

I have two C programs that need to run simultaneously on a small computer in order to do some simulation. One program will receive user-input from a separate Windows machine, the other program will communicate with another separate machine in order to actually perform the simulation algorithms. They will both always be connected and always have ports open while the small computer is active.

The problem I have run into is that the user-inputted information will be used within program running the algorithms, i.e.: the one not constantly listening for user input. I can't see myself merging the two programs as the simulation requires very fast communication, and can't be bogged down by listening on the other port. And this setup obviously prohibits simply linking the files or fancy header work.

So, anyone have any ideas? One thing they could do is read/write data from/to a file in a hardcoded location, but that seems pretty cheesy. Should I just scrap the current outline of the project and go a different direction?

Thanks in advance!

Marcus Müller
  • 34,677
  • 4
  • 53
  • 94
LowLevelSoCal
  • 15
  • 3
  • what OS the programs are running on ? – Marcia Ong Jul 02 '18 at 23:46
  • 1
    How about merging them so that they run as two separate threads in the same process? Then they can directly access each other’s data (you’ll need to add synchronization mechanisms before they can do so safely though) – Jeremy Friesner Jul 02 '18 at 23:51
  • 1
    It's going to be much slower to communicate between the two processes than it will to handle both in a single one. – Ken White Jul 02 '18 at 23:54
  • You can do quite effectively in a single program that has either a poll/select loop, multiple different processes or, better yet, multiple threads. Or a combination of the above. My other answer may be useful: https://stackoverflow.com/questions/37534710/relative-merits-between-one-thread-per-client-and-queuing-thread-models-for-a-th/37535626#37535626 – Craig Estey Jul 02 '18 at 23:59

1 Answers1

3

If possible, I would build this as a single process running two threads, one listening for input from the Windows machine, the other running the simulation itself.

This would make it fairly easy for the listening thread to simply update the data in-place, where the simulation thread will use it.

The one tricky part is coordinating the two--if the simulation thread tries to read data while the listening thread is trying to write it, you're liable to get corrupted data.

To avoid this, you could (for one example) have two separate data areas, one for the current data, and one for the next generation of data, as it's being updated by the listening thread.

The listening thread and the simulation thread then have an atomic flag (or maybe two) to indicate which data area each should use at a given time.

Jerry Coffin
  • 476,176
  • 80
  • 629
  • 1,111