c++ - reales - libro de android studio en español pdf

¿Por qué Windows 10 inicia hilos adicionales en mi programa?

Question

Con Visual Studio 2015, en un nuevo proyecto de C ++ vacío, genere lo siguiente para la aplicación de la Consola:

int main() {
return 0;
}

Establezca un punto de ruptura en la devolución e inicie el programa en el depurador. En Windows 7, a partir del punto de ruptura, este programa solo tiene un hilo. Pero en Windows 10, tiene cinco (!) Subprocesos: el subproceso principal y cuatro "subprocesos de trabajo" que esperan en un objeto de sincronización.

¿Quién está iniciando el grupo de hilos (o cómo lo descubro)?

Answer 1

Es el conjunto de subprocesos predeterminado. https://docs.microsoft.com/en-us/windows/desktop/procthread/thread-pools

Cada proceso tiene un grupo de subprocesos predeterminado.

Answer 2

La bola de cristal dice que la ventana Debug> Windows> Threads muestra estos hilos en ntdll.dll!TppWorkerThread . Asegúrese de habilitar el servidor de símbolos de Microsoft para verlo usted mismo, use Herramientas> Opciones> Depuración> Símbolos.

Esto también ocurre en el VS2013, por lo que definitivamente no está causado por las nuevas funciones de diagnóstico del VS2015, la conjetura de @Adam no puede ser correcta.

TppWorkerThread () es el punto de entrada para un subproceso de grupo de subprocesos. Cuando configuro un punto de interrupción con Debug> Nuevo punto de interrupción> Función punto de interrupción en esta función. Tuve la suerte de capturar este seguimiento de pila para el primer subproceso de subprocesos cuando el segundo subproceso de subprocesos comenzó a ejecutarse:

 ntdll.dll!_NtOpenFile@24() Unknown
ntdll.dll!LdrpMapDllNtFileName() Unknown
ntdll.dll!LdrpMapDllSearchPath() Unknown
ntdll.dll!LdrpProcessWork() Unknown
ntdll.dll!_LdrpWorkCallback@12() Unknown
ntdll.dll!TppWorkpExecuteCallback() Unknown
ntdll.dll!TppWorkerThread() Unknown
kernel32.dll!@BaseThreadInitThunk@12() Unknown
ntdll.dll!__RtlUserThreadStart() Unknown
> ntdll.dll!__RtlUserThreadStart@8() Unknown

Claramente, el cargador está utilizando el conjunto de subprocesos en Windows 10 para cargar archivos DLL. Eso es ciertamente nuevo :) En este punto, el hilo principal también se está ejecutando en el cargador, la concurrencia en el trabajo.

Así que Windows 10 está aprovechando múltiples núcleos para que el proceso se inicialice más rápido. Muy una característica, no un error :)