在 c++ dll 中启动一个线程，从一个 C# wpf 开始一个线程，内部需要一个线程

Question

I have a C# / WPF application that runs functions from a c++ dll, and returns data into a callback.

To avoid locking the UI, I start a thread in C# that starts a new thread in the dll.

c#

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();

}

This seems redundant, as I am starting a thread just to start a thread. But if i do not start a new c# thread, the UI locks up. If I just run the function in c++, without starting a new c++ thread, I see strange issues with my returned data, where the latency will rise and fall. In a new thread, it is stable. For example, the latency of my callback data is 6ms when I launch the application. When the application is minimised for a period of time, or I am using another application while it is running, the latency will rise to 800ms or more.

My question is:

Do I need to run a thread-inside-a-thread like this? Or is there a simpler way?

Answer 1

About the use of threads in both C # and C ++. Keep in mind that they will be different contexts, so if the following questions have affirmative answers, continue to use them.

1 - In your WPF form, do you want to allow your user to perform other actions while the routine is not completed (responsiveness)?

2 - In the routine created in C ++, consumed by C # through the DLL, are there other activities that can be performed in parallel to the main flow?

As for the latency issue, I would advise you to change your approach a bit. Instead of instantiating new threads whenever you use your C ++ routine (new Thread(StartTracking)). Try to use the pool of threads managed by.Net . In the past, I have seen significant performance improvements in adopting this approach.

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