相关疑难解决方法(0)

我正在研究一个多线程的C#Windows应用程序,它经常调用本机dll.阻塞调用有时会持续很长时间.

在某些情况下,我想在主线程的某些工作线程上取消这些阻塞调用我正在使用的本机API为此提供了一个函数:

HRESULT CancelBlockingCall(DWORD ThreadID)

尽管CancelBlockingCall()的文档并不十分清楚,但我相信我需要为操作系统级别的线程传递ThreadID.基于我从CancelBlockingCall()得到的返回码,我意识到Thread.ManagedThreadID不是我需要的.我在msdn上找到了以下内容(参见注释):

操作系统ThreadId与托管线程没有固定的关系,因为非托管主机可以控制托管和非托管线程之间的关系.具体而言,复杂的主机可以使用CLR Hosting API针对同一操作系统线程调度许多托管线程,或者在不同操作系统线程之间移动托管线程.

这是否意味着我无法为托管线程正确调用CancelBlockingCall()？是否无法确定托管线程当前正在执行的OS级线程的ThreadId？

我知道我应该不依赖于有托管和非托管线程之间的一个一对一的映射。从MSDN：

操作系统 ThreadId 与托管线程没有固定的关系，因为非托管主机可以控制托管线程和非托管线程之间的关系。具体来说，一个复杂的主机可以使用 Fiber API 来针对同一个操作系统线程调度多个托管线程，或者在不同的操作系统线程之间移动一个托管线程。

但在现实生活中，这样的 CLR 主机存在吗？（如果是这样，它们是什么？）我刚刚回答了一个相关的问题，我想知道我的建议对于那个特定案例有多么糟糕。