从 C# wpf 应用程序在 c++ dll 中启动一个线程，我需要一个线程内的线程吗？答案

【问题标题】：Starting a thread in a c++ dll, from a C# wpf application, do I need a thread inside a thread?从 C# wpf 应用程序在 c++ dll 中启动一个线程，我需要一个线程内的线程吗？
【发布时间】：2020-11-09 20:21:45
【问题描述】：

我有一个 C#/WPF 应用程序，它从 c++ dll 运行函数，并将数据返回到回调中。

为了避免锁定 UI，我在 C# 中启动了一个线程，该线程在 dll 中启动了一个新线程。

Thread threadZ = new Thread(StartTracking);
threadZ.IsBackground = true;
threadZ.Start();

c++

__declspec(dllexport) void StartTracking()
{

    std::thread procThread = std::thread([&]() {
        m.ttrack->Connect(callback, callbackFrames); });

    procThread.join();

}

这似乎是多余的，因为我启动一个线程只是为了启动一个线程。但是如果我不启动一个新的 c# 线程，UI 就会锁定。如果我只是在 C++ 中运行该函数，而不启动新的 C++ 线程，我会看到返回的数据出现奇怪的问题，延迟会上升和下降。在新线程中，它是稳定的。例如，当我启动应用程序时，我的回调数据的延迟是 6 毫秒。当应用程序最小化一段时间，或者我正在使用另一个应用程序时，延迟会上升到 800ms 或更多。

我的问题是：

我需要像这样运行线程内线程吗？还是有更简单的方法？

【问题讨论】：

你只需要一个 C# 线程。如果您希望在应用程序结束时终止它，您只需要IsBackground = true。关于“奇怪的返回数据”和“延迟”，我们需要更多细节。我看不出线程如何让事情变得更好。
添加了更多信息。似乎如果我只是启动一个 C# 线程，我的数据回调的延迟会以某种方式与 UI 相关联。在它运行一个小时左右后，随着应用程序的最小化，延迟会增加。如果我如上所述使用 c++ 线程，则不会发生这种情况。
这里有两个问题。 “我需要两个线程吗”的答案是“不，只需在 C# 中创建一个”。第二个问题的答案是“创建另一个问题，提供的信息比您提供的几乎所有信息都多，我们也许可以帮助您”。
对于 6 毫秒的回调，您根本不需要线程。这不是 UI 感觉反应迟钝的时候。如果它死锁，那么你应该解决这个死锁。

标签： c# c++ multithreading

【解决方案1】：

关于 C# 和 C++ 中线程的使用。请记住，它们将是不同的上下文，因此如果以下问题有肯定的答案，请继续使用它们。

1 - 在您的 WPF 表单中，您是否希望您的用户在例程未完成时执行其他操作（响应性）？

2 - 在 C++ 创建的例程中，C# 通过 DLL 使用的例程中，是否还有其他可以与主流程并行执行的活动？

至于延迟问题，我建议您稍微改变一下方法。而不是在您使用 C++ 例程 (new Thread(StartTracking)) 时实例化新线程。尝试使用the pool of threads managed by .Net。过去，我看到采用这种方法后性能得到了显着提升。

ThreadPool.QueueUserWorkItem((x)=> StartTracking);

【讨论】：