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

Improve this question
1
  • 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, 2022 at 13:44

1 Answer 1

Reset to default
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.

Improve this answer
5
  • 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, 2022 at 3:43
  • 2
    The phenomenon @MartinMaat is describing is called thrashing btw en.wikipedia.org/wiki/Thrashing_(computer_science)
    – SirHawrk
    Jun 10, 2022 at 9: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.
    – candied_orange
    Jun 10, 2022 at 16:43
  • @MartinMaat: even better is using the myriad of built-in classes designed for this sort of task.
    – whatsisname
    Jul 21, 2022 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. <br> "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:docs.microsoft.com/en-us/dotnet/standard/parallel-programming/…
    – Athadu
    Jul 22, 2022 at 1:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.