|
|
The .NET Framework's ThreadPool management leaves much to be desired. My assumption was that a managed threadpool would grab a small subset of the total threads given to the CLR & give/take from this pool intelligently.
Instead what I've found is that this is true only until "number of threads in the pool" = "max allowed threads." By using the managed methods ("ASyncCallback / BeginInvoke & EndInvoke" or ThreadPool's "QueueUserWorkItem") it's very easy completely exhaust your thread limit, at which point all other processes within your application are blocked until the thread pool queue is clear.
The only way to get the behavior I expected is to use the "ThreadStart delegate & threadInstance.Start()" approach. This hands-on approach allows you to manually monitor the total number of threads started, stopped, etc. and prevent the system from overallocating & using up my target # of resources.
Here's a pseudo code comparison:
Approach #1, managed thread pool:
1: Add 1000 threads to the thread pool that start via thread pool manager
2: Send info to the user about current thread status
Approach #2, threadInstance.start()
1: Create & start N threads, wait until #1 completes before starting #N+1, etc., work until 1000 threads have been created
2: Send info to the user about current thread status
W/ Approach #1, everything goes smoothly until the Max threads limit is reached, at which point line 2 is blocked & placed at the back of the queue. Since the thread pool does FIFO, the user does not receive feedback until the # of active threads falls to MaxThreads-1.
W/ Approach #2, I am always able to send feedback to users because the 1000 worker threads & user interface threads never battle for the same resources. Far less elegant but far more effective. |
|
Note: Only registered ShinyDonkey.com users
can post images. Only administrators can delete images.
New messages disabled indefinitely due to SPAM.