0

I'm working on an embedded system with very few resources available, I seem to be able to launch individual threads without too much delay elsewhere, but when I queue a task in the ThreadPool as mentioned in the title, there is a very noticeable graphical delay while it is queuing or performing the task.

The call looks like:

NetManager nPart = new NetManager();
ThreadPool.QueueUserWorkItem(nPart.DoPartCountUpdate, _partManager.PartProduced);

The lag is most noticeable on the fist call, subsequent calls appear to cause less issues (most of the time).

I wanted to use this to avoid creating too many threads.

Edit:

To be honest, this is probably a case where the embedded device should just have more than 1 gig of RAM while running Win 7 embedded... nonetheless, maybe a better way to queue the task.

Edit 2:

I've tried doing things like

int min, max;
ThreadPool.GetAvailableThreads(out min, out max);
ThreadPool.SetMinThreads((min + 5), (max + 5));

But the lag does not change noticably in any way. At this point I'd rather use something else as I can't seem to get the thread pool to react quickly enough.

Simply launching my own thread seems like a better option at this point, unless there is a better alternative?

I should also note that it is definitely the CPU that is the bottleneck. I can see it maxing out at 100% usage when the lag happens.

jeb
  • 78,592
  • 17
  • 171
  • 225
Justin
  • 533
  • 1
  • 7
  • 18
  • 1
    You could just send some operation to the thread pool when starting your application, to make sure that at least one thread gets spun up there. This is typically not needed on non-embedded devices I've worked on, but it seems that this machine's runtime is a bit more...conservative (understandably so)...in spinning up new threads for the thread pool because of the more limited resources. In theory you could create and maintain your own thread pool with a more resource intensive plan for pooling threads, but hopefully that won't be necessary. – Servy Oct 30 '15 at 20:18
  • Ya, that's definitely what it is. The more times successively that function is called like that, without too much time in between, the less noticeable the lag is, and eventually it isn't really noticeable at all. But then I noticed if the machine idles for a bit, .NET is likely disposing those resources as the next call will lag again as much as the 1st time. I can maybe look into some way of keeping the threadpool ready as you suggested. – Justin Oct 30 '15 at 20:26
  • Have you tried `Task.Run`? – Domysee Oct 30 '15 at 20:38
  • I had thought about it but as far as I understand that would require restructuring some of the functions etc. to be async/await, which is a little much most likely. – Justin Oct 30 '15 at 20:43
  • 2
    Task.Run also uses the ThreadPool, no reason it should be quicker. You could look into ThreadPool.MinThreads, I don't know how that's set in embedded. – H H Oct 30 '15 at 21:18
  • See also [Multiple Tasks slows down](https://stackoverflow.com/q/7393938) and [How long should QueueUserWorkItem take to execute?](https://stackoverflow.com/q/24739423), among others. – Peter Duniho Oct 31 '15 at 00:42
  • I've done something like int min, max; ThreadPool.GetMinThreads(out min, out max); ThreadPool.SetMinThreads((min + 5), (max + 5)); But haven't had much success with getting it to actually be ready for the call to QueueUserWorkItem. I'll look into some other options. – Justin Nov 02 '15 at 17:04

0 Answers0