-1

I'm writing a windows forms program (C++/CLI) that calls an executable program multiple times within a large 'for' loop. I want to do the calls to the executable in parallel since it takes up to a minute to run once.

The key part of the windows forms code is the large for loop (actually 2 loops):

for (int a=0; a<1000; a++){
   for (int b=0; b<100; b++){
       int run = a*100 + b;
       char startstr[50], configstr[50]; strcpy(startstr, "solver.exe");
       sprintf(configstr, " %d %d %d", run, a, b);
       strcat(startstr, configstr);
       CreateProcessA(NULL, startstr,......) ;
   }
}

The integers "run", "a" and "b" are used by the solver.exe program. "Run" is used to write a unique output text file from each program run. "a" and "b" are numbers used to read specific input text files. These are not unique to each run.

I'm not waiting after each call to "CreateProcess" as I want these to execute in parallel.

Currently my code runs and appears to work correctly. However, it swans a huge number of instances of the solver.exe program at once causing my computer to become very slow until everything finishes.

My question is, how can I create a queue that limits the number of concurrent processes (for example to the number of physical cores on the machine) so that they don't all try to run at the same time? Memory may also be an issue when the for loops are set larger.

A secondary question is, could potential concurrent file reads by different instances of solver.exe create a problem? (I can fix this but don't want to if I don't need to.)

I'm familiar with openmp and C but this is my first attempt at running parallel processes in a windows forms program.

Thanks

user3281744
  • 31
  • 4
  • Does this have to be a separate .exe? If you control the solver code, it would make things much easier if it's a DLL. – Stu Mar 18 '16 at 01:40
  • "could potential concurrent file reads by different instances of solver.exe create a problem?" That depends -- if it's just reading, then it should be fine as long as you make sure to not lock the file in any way. – Stu Mar 18 '16 at 01:41
  • Regardless, this is a potential duplicate. Look at this and see if it fits your needs: http://stackoverflow.com/questions/42531/how-do-i-call-createprocess-in-c-to-launch-a-windows-executable – Stu Mar 18 '16 at 01:43
  • off topic: you can save yourself a lot of trouble with `std::stringstream`. `std::stringstream startstr; startstr <<"solver.exe "<< run << ' ' << a << ' ' << b; CreateProcessA(NULL, startstr.str().c_str(),......) ;` – user4581301 Mar 18 '16 at 01:45
  • Yes the files are just read not written. – user3281744 Mar 18 '16 at 03:48
  • No it doesn't have to be a separate .exe. I have control over it. The .exe does use embedded resource files though; I'm not sure if that changes things. Yes I've seen that post; I can't see where it talks about queuing the number of processes though. – user3281744 Mar 18 '16 at 03:55

1 Answers1

0

I've managed to do what I want using the OpenMP function "parallel for" to run the outer loop in parallel and the function omp_set_num_threads() to set the number of concurrent processes. As suggested, the concurrent file reads haven't caused any problems on my system.

user3281744
  • 31
  • 4