Concord Threading Model

Considerations when calling the API: Most of the Concord API may be called on any thread. However, the Dispatcher requires knowing the current component. So in order to use the Concord API from a thread that your code creates, or from some sort of Visual Studio worker thread (not the main thread, and not one of the debugger threads), the thread must register with the Dispatching using DkmComponentManager.InitializeThread. One set of methods that cannot be called on any thread, are the various methods that raise events. These APIs should generally only be called on the event thread. These will fail when called from another thread. The only other restriction on what thread can call a method is that there are a few APIs that either accept or return COM objects. These APIs either require that they are called from the MTA (for interfaces which are MTA-only) or Visual Studio’s main STA (for interfaces which are implemented there).

Consideration when implementing Concord interfaces: Concord will nearly always call implementations on one of two threads – the request thread, which handles requests coming from the IDE, and the event thread, which handles debug events coming from the target process. This said it is possible for callers to create their own threads, so implementers shouldn’t assume that only the two threads are possible. For components that wish to prevent reentrancy, the component can set ‘Synchronized="true"’ in its component configuration. This will instruct the dispatcher to essentially place a lock around the component which it will enter/leave before calling the component. Such components can use DkmComponentManager.AllowComponentReentrancy/ DkmComponentManager.DisableComponentReentrancy if there are scenarios where they need to temporarily leave and reenter the lock.