29.03.2020 20:52
ForserX 5 3400 Источник
В некотором 2017 году, во время отладки в VS, производительность в проекте падала на ~80%, превращая игру в сборник различных ассинхронных кадров. Виновником торжества стала функция SetThreadName внутри пула. Кто не знаком — ThreadPool — некий manager, отвечающий за параллельное выполнение одинакового кода. К примеру, так можно распралелить циклы. Суть его в создании нескольких потоков (по 1 воркеру на каждое ядро) и перевод в ожидание/удаление по завершению работы.

SetThreadName выглядел следующим образом: 

void SetThreadName(DWORD dwThreadID, const char* threadName) {
    THREADNAME_INFO info;
    info.dwType = 0x1000;
    info.szName = threadName;
    info.dwThreadID = dwThreadID;
    info.dwFlags = 0;
#pragma warning(push)
#pragma warning(disable: 6320 6322)
    __try{
        RaiseException(MS_VC_EXCEPTION, 0, sizeof(info) / sizeof(ULONG_PTR), (ULONG_PTR*)&info);
    }
    __except (EXCEPTION_EXECUTE_HANDLER){
    }
#pragma warning(pop)
}

В новом WinSDK старый добрый хак с RaiseException можно заменить на SetThreadDescription, что по итогу спасает ситуацию. Т.к. RaiseException довольно медленная операция.

Из ситуации было несколько оптимальных выходов:

  1. Не давать воркерам имена в принципе.
  2. Давать только при ините и сохранять потоки в режиме ожидания. Такой способ плох при присоединении к запущенному процессу — имён мы уже не узнаем.
  3. Воркеры не уничтожаются. Каждую задачу проверяют наличие подключенного отладчика, если до этого он был отключен. IsDebuggerPresent