I have a project with DirectX support. In this program uses two threads. One is a dedicated message loop and the second is executing DirectX API's. The question is about ending such program. The WM_CLOSE sends asynchronous command, that stops rendering and exits DirectX loop too. After that it destroys the window. Everything works fine. The question is, is this algorithm OK? Should the window's thread or the DirectX thread be synchronized (dependent)?
The main area of synchronization is between your 'windows thread' and the thread you call 'DXGI' from for Present.
See Microsoft Docs.
When executing, you need to be careful, if the close starts releasing our impacting resources in your windows main thread, this can affect your DirectX thread. As another answer has indicated, the Present is your point of Sync. You maybe best to at the least use some atomic flags cross the threads to ensure that your close action has not started at the same time as you are entering a critical part of your draw execution.
If for example, you built a synchronous close function called from your parent thread that waited on other child threads to complete and close then that is one approach. Once you start into the world of deferred contexts and further multi-threading your game. A common sync point for critical system action will be more important (actions such as close).
Having gone through the multithreading pain myself, the key point I have found is that destruction of objects in child threads causes all sorts of headaches.