views:

309

answers:

2

I made a custom ThreadPool optimized for my specific needs. However, when there are multiple AppDomains in the process, the CLR ThreadPool is able to be shared across all the AppDomains and I would like to be able to reproduce this behavior.

This could be done using MarshalByRefObject and Remoting in order to create a distributed ThreadPool, but I fear that it will add unwanted overhead since the key goal of the custom thread pool is performance.

Another theoretical solution would be to hack the AppDomain memory boundary using an unmanaged object. If I'm correct, the memory boundary in AppDomain only apply to managed objects, so there could be one managed wrapper in each AppDomain all pointing to the same unmanaged object.

So my questions are:

  1. Is there a way to make a custom thread pool using remoting with minimal overhead?
  2. If not, is it possible to share an unmanaged object across AppDomain?
+1  A: 

Create a new threadpool instance in each appdomain, but then use a semaphore to control the total number of threads running across all instances. This means you can still get the same total concurrent jobs processed, but don't have the grief of marshalling.

The MSDN docs have an example.

Steve Cooper
A thread pool is optimal when is has one thread per cpu. With your solution, threads are not shared across appdomain. So if you have five AppDomain queuing work items and have only 4 cpu core, you need 5 threads to be able to execute all the work items, this is not optimal.
SelflessCoder
Optimal for what? If your threads may be IO-bound, then one-thread-per-cpu is extremely suboptimal. The framework's threadpool originally maxed out at 25/cpu, and is now 250/cpu; never 1/cpu. A semaphore using Threading.ThreadPool.GetMaxThreads() would simulate the framework's current operation.With remoting, there's always going to be the marshalling overhead, so each thread is going to have a higher startup cost than you'd probably prefer. As to sharing an unmanaged object; sounds to me like you're opening yourself a world of pain and bugs. I wouldn't do it.
Steve Cooper
You are right that I should have stated optimal for cpu bound processing. However, even for IO bound processing, blocking a threadpool thread with a IO operation is rarely a good idea, it should use IO completion port instead.
SelflessCoder
A: 

After thinking more about it, it's probably a bad idea to try to reimplement a process wide ThreadPool, the CLR ThreadPool is already optimized for this.

For my case, I wanted more flexibility to be able to prioritize work items queued into the pool, this can be done with a layer built on top of the existing CLR ThreadPool.

SelflessCoder