0

I have a program that accepts computer names and then will perform CIM session tasks. The computer names are passed in from the user input and separated by "," (ex: program.exe -computers pc1, pc2, pc3). Then after accepting the input the program will multi-thread against the computer names at the same time.

I'm stuck and trying to figure out the best way to accept over 500 computer names passed into the program while being able to multi-thread. Should I save all output to a file or just pass in all the computer names?

The program is c# written in .net core on a windows machine

robni
  • 103
  • 4
James
  • 11
  • 3
  • FYI multi-threading has nothing to do with the problem you described, it should have no influence on how you parse command line arguments. – whatsisname Jul 21 '22 at 13:44

1 Answers1

4

"Best" is of course subjective, but in this case I think it boils down to usability.

If you are going to have humans executing this program and typing in 500 computer names, that's not something you want to do on the command line. Dump them to a text file, and pass the filename in as a command line argument instead. Read the file in the main thread, and then multi-thread once you have all the computer names you need to process (NB: as @MartinMaat and @SirHawrk mentioned in the comments, don't try to spin up 500 threads, as that will lead to thrashing and you won't get your results any sooner). This has the additional advantage that it can be easily re-run without re-typing 500 names (or copy-pasting from somewhere), and you have all the capabilities of modifying your set of names using your favorite file editor.

If this will be executed from another program, it's no problem to put all those names on the command line. However, it's also no problem to dump them all to a file and pass it in as above.

mmathis
  • 5,398
  • 23
  • 33
  • 5
    Starting a couple of hundred threads will likely not make the results available any sooner. If you must multi-thread (I would start without it), limit the number of running threads to a fixed number, like 4 or so, do not start a new one before a slot becomes available, experiment to get the best results. – Martin Maat Jun 10 '22 at 03:43
  • 2
    The phenomenon @MartinMaat is describing is called thrashing btw https://en.wikipedia.org/wiki/Thrashing_(computer_science) – SirHawrk Jun 10 '22 at 09:47
  • Every thread has its own overhead and startup time. Making a new one every time you go to do something usually doesn't help. However, they can be very useful for separating [bounded work](https://softwareengineering.stackexchange.com/questions/258677/i-o-bound-or-cpu-bound). – candied_orange Jun 10 '22 at 16:43
  • @MartinMaat: even better is using the myriad of built-in classes designed for this sort of task. – whatsisname Jul 21 '22 at 13:46
  • In .net core, you can use 'Task based asynchronous programming'. Tasks are lighter than threads. Tasks are queued to a ThreadPool. You do not have to be concerned with 'thrashing'. The 'thrashing' issue that was mentioned is managed by the ThreadPool.
    "Behind the scenes, tasks are queued to the ThreadPool, which has been enhanced with algorithms that determine and adjust to the number of threads and that provide load balancing to maximize throughput." - From MS documentation:https://docs.microsoft.com/en-us/dotnet/standard/parallel-programming/task-based-asynchronous-programming     – Athadu Jul 22 '22 at 01:49