我根据自己的特定需求制作了自定义ThreadPool。但是,当进程中有多个AppDomain时,可以在所有AppDomain上共享CLR ThreadPool,我希望能够重现此行为。
这可以使用MarshalByRefObject和Remoting来创建分布式ThreadPool,但我担心它会增加不必要的开销,因为自定义线程池的关键目标是性能。
另一个理论解决方案是使用非托管对象破解AppDomain内存边界。如果我是正确的,AppDomain中的内存边界仅适用于托管对象,因此每个AppDomain中可能有一个托管包装器都指向同一个非托管对象。
所以我的问题是:
答案 0 :(得分:2)
在每个appdomain中创建一个新的线程池实例,然后使用semaphore来控制在所有实例中运行的线程总数。这意味着您仍然可以处理相同的总并发作业,但不会感到悲伤。
MSDN文档有一个例子。
答案 1 :(得分:0)
在仔细考虑之后,尝试重新实现一个进程范围的ThreadPool可能是一个坏主意,CLR ThreadPool已经针对此进行了优化。
对于我的情况,我希望能够更灵活地排队排队到池中的工作项,这可以通过在现有CLR ThreadPool之上构建的层来完成。