.Net 如何创建在进程的所有 AppDomain 之间共享的自定义线程池？
我制作了一个针对我的特定需求进行优化的自定义线程池。但是，当进程中有多个 AppDomain 时，CLR ThreadPool 能够在所有 AppDomain 之间共享，我希望能够重现这种行为。
这可以使用 MarshalByRefObject 和 Remoting 来完成，以便创建分布式线程池，但我担心这会增加不必要的开销，因为自定义线程池的关键目标是性能。
另一个理论上的解决方案是使用非托管对象破解 AppDomain 内存边界。如果我是正确的，AppDomain 中的内存边界仅适用于托管对象，因此每个 AppDomain 中可能有一个托管包装器都指向同一个非托管对象。
所以我的问题是：
- 有没有办法进行定制 使用远程处理的线程池 最小的开销？
- 如果不是的话，是不是 可以共享非托管 跨AppDomain的对象？
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:
- Is there a way to make a custom
thread pool using remoting with
minimal overhead? - If not, is it
possible to share an unmanaged
object across AppDomain?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
在每个应用程序域中创建一个新的线程池实例，然后使用 信号量 控制所有实例上运行的线程总数。这意味着您仍然可以处理相同的并发作业总数，但不必担心编组问题。
MSDN 文档有一个示例。
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.
经过更多思考后，尝试重新实现进程范围的 ThreadPool 可能不是一个好主意，CLR ThreadPool 已经为此进行了优化。
就我而言，我希望能够更加灵活地对排队到池中的工作项进行优先级排序，这可以通过构建在现有 CLR ThreadPool 之上的层来完成。
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.