0

I have about 10.000 jobs that I want to be handled by approx 100 threads. Once a thread finished, the free 'slot' should get a new job untill there are no more jobs available.

Side note: processor load is not an issue, these jobs are mostly waiting for results or (socket) timeouts. And the amount of 100 is something that I am going to play with to find an optimum. Each job will take between 2 seconds and 5 minutes. So I want to assign new jobs to free threads and not pre-assign all jobs to threads.

My problem is that I am not sure how to do this. Im primarily using Visual Basic .Net (but C# is also ok).

I tried to make an array of threads but since each job/thread also returns a value (it also takes 2 input vars), I used 'withevents' and found out that you cannot do that on an array... maybe a collection would work? But I also need a way to manage the threads and feed them new jobs... And all results should go back to the main-form (thread)...

I have it all running in one thread, but now I want to speed up.

And then I though: Actually this is a rather common problem. There is a bunch of work to be done that needs to be distributed over an amount of worker threads.... So thats why I am asking. Whats the most common solution here?

I tried to make it question as generic as possible, so lots of people with the same kind of problem can be helped with your reply. Thanks!

Edit: What I want to do in more detail is the following. I currently have about 1200 connected sensors that I want to read from via sockets. First thing I want to know is if the device is online (can connect on ip:port) or not. After it connects it will be depending on the device type. The device type is known after connect and Some devices I just read back a sensor value. Other devices need calibration to be performed, taking up to 5 minutes with mostly wait times and some reading/setting of values. All via the socket. Some even have FTP that I need to download a file from, but that I do via socket to. My problem: Lot's of waiting time, so lot's of possibility to do things paralel and speed it up hugely. My starting point is a list of ip:port addresses and I want to end up with a file with that shows the results and the results are also shown on a textbox on the main form (next to a start/pause/stop button)

Hasse
  • 383
  • 3
  • 11
  • 2
    Optimum is likely much closer to 2 or 3 times the number of cpu cores. One a large 64-core server, 100 might be too small. On a typical desktop, it's probably much too large. – Joel Coehoorn Nov 19 '20 at 21:15
  • 4
    Also, this is what [ThreadPool](https://learn.microsoft.com/en-us/dotnet/api/system.threading.threadpool.queueuserworkitem?view=net-5.0) is for. – Joel Coehoorn Nov 19 '20 at 21:16
  • 2
    Finally, are these jobs really cpu-limited, or are they limited by resources like disk or network throughput? If the latter, you might want even fewer threads, and instead await [asynchronous operations](https://learn.microsoft.com/en-us/dotnet/csharp/programming-guide/concepts/async/) on the same thread with `Task`. – Joel Coehoorn Nov 19 '20 at 21:18
  • Is it an option to use asynchronous socket operations? In that case you could use tasks and async/await instead of threads, and have a more memory-efficient solution. Each thread requires 1MB of RAM just for its stack, and taxes the operating system with extra work (allocation of time-slices for each thread, context switching etc). With async/await you could do the same amount of work using only few threads from the `ThreadPool`. – Theodor Zoulias Nov 20 '20 at 04:36
  • 1
    "I tried to make it question as generic as possible, so lots of people with the same kind of problem can be helped with your reply." - Please don't. This is exactly the opposite of what happens. Please make your question as specific as possible so that people can recognise you problem which then will make it far more useful. – Enigmativity Nov 20 '20 at 07:31

1 Answers1

0

This was very helpfull: Multi Threading with Return value : vb.net

It explains the concept of a BackgroundWorker which takes away a lot of the hassle. I am now trying to see where it will bring me.

Hasse
  • 383
  • 3
  • 11
  • The `BackgroundWorker` is technologically obsolete. You may want to take a look at this question: [Async/await vs BackgroundWorker](https://stackoverflow.com/questions/12414601/async-await-vs-backgroundworker). Disclaimer: it's an old question, and mine is the only recent answer. – Theodor Zoulias Nov 25 '20 at 23:33