Subprocesamiento de Windows: _beginthread vs _beginthreadex vs CreateThread C ++

¿Cuál es una mejor manera de comenzar un hilo _beginthread, _beginthreadxo CreateThread?

Estoy tratando de determinar cuáles son las ventajas / desventajas de _beginthread, _beginthreadexy CreateThread. Todas estas funciones devuelven un identificador de subproceso a un subproceso recién creado, ya sé que CreateThread proporciona un poco de información adicional cuando se produce un error (se puede verificar llamando GetLastError) ... pero ¿cuáles son algunas cosas que debo considerar cuando ' Estoy usando estas funciones?

Estoy trabajando con una aplicación de Windows, por lo que la compatibilidad multiplataforma ya está fuera de discusión.

He revisado la documentación de msdn y simplemente no puedo entender, por ejemplo, por qué alguien decidiría usar _beginthread en lugar de CreateThread o viceversa.

¡Salud!

Actualización: OK, gracias por toda la información, también he leído en un par de lugares a los que no puedo llamar WaitForSingleObject()si los usaba _beginthread(), pero si llamo _endthread()en el hilo, ¿no debería funcionar? ¿Cuál es el trato allí?

CreateThread() es una llamada API de Win32 sin procesar para crear otro subproceso de control a nivel del núcleo.

_beginthread()& _beginthreadex()son llamadas de biblioteca de tiempo de ejecución C que llaman CreateThread()detrás de escena. Una vez que CreateThread()ha regresado, _beginthread/ex()se encarga de la contabilidad adicional para que la biblioteca de tiempo de ejecución C sea utilizable y coherente en el nuevo hilo.

En C ++, seguramente debería usarlo a _beginthreadex()menos que no se vincule a la biblioteca de tiempo de ejecución de C (también conocido como MSVCRT * .dll / .lib).

Hay varias diferencias entre _beginthread()y _beginthreadex(). _beginthreadex()fue hecho para actuar más como CreateThread()(en ambos parámetros y cómo se comporta).

Como Drew Hall menciona, si está utilizando el tiempo de ejecución C / C ++, debe usar _beginthread()/ en _beginthreadex()lugar de CreateThread()para que el tiempo de ejecución tenga la oportunidad de realizar su propia inicialización de subprocesos (configuración del almacenamiento local de subprocesos, etc.).

En la práctica, esto significa que CreateThread()su código nunca debería ser usado directamente por su código.

Los documentos de MSDN para _beginthread()/ _beginthreadex()tienen bastante detalle sobre las diferencias, una de las más importantes es que, dado que el identificador de hilo para un hilo creado por _beginthread()se cierra automáticamente por el CRT cuando el hilo sale, "si el hilo generado por _beginthread sale rápidamente, el identificador devuelto al llamador de _beginthread podría no ser válido o, peor aún, señalar a otro hilo ".

Esto es lo que dicen los comentarios _beginthreadex()en la fuente CRT:

Differences between _beginthread/_endthread and the "ex" versions:

1)  _beginthreadex takes the 3 extra parameters to CreateThread
  which are lacking in _beginthread():
    A) security descriptor for the new thread
    B) initial thread state (running/asleep)
    C) pointer to return ID of newly created thread

2)  The routine passed to _beginthread() must be __cdecl and has
  no return code, but the routine passed to _beginthreadex()
  must be __stdcall and returns a thread exit code.  _endthread
  likewise takes no parameter and calls ExitThread() with a
  parameter of zero, but _endthreadex() takes a parameter as
  thread exit code.

3)  _endthread implicitly closes the handle to the thread, but
  _endthreadex does not!

4)  _beginthread returns -1 for failure, _beginthreadex returns
  0 for failure (just like CreateThread).

Actualización de enero de 2013:

El CRT para VS 2012 tiene un bit de inicialización adicional realizado _beginthreadex(): si el proceso es una "aplicación empaquetada" (si se devuelve algo útil GetCurrentPackageId()), el tiempo de ejecución inicializará el MTA en el subproceso recién creado.

En general, lo correcto es llamar _beginthread()/_endthread()(o las ex()variantes). Sin embargo, si se utiliza el CRT como .dll, el estado CRT se ha inicializado correctamente y destruido como el CRT DllMainse llamará con DLL_THREAD_ATTACHy DLL_THREAD_DETACHal llamar CreateThread()y ExitThread()o regresar, respectivamente.

El DllMaincódigo para el CRT se puede encontrar en el directorio de instalación de VS en VC \ crt \ src \ crtlib.c.

Este es el código en el núcleo de _beginthreadex(ver crt\src\threadex.c):

    /*
     * Create the new thread using the parameters supplied by the caller.
     */
    if ( (thdl = (uintptr_t)
          CreateThread( (LPSECURITY_ATTRIBUTES)security,
                        stacksize,
                        _threadstartex,
                        (LPVOID)ptd,
                        createflag,
                        (LPDWORD)thrdaddr))
         == (uintptr_t)0 )
    {
            err = GetLastError();
            goto error_return;
    }

El resto de _beginthreadexinicializa la estructura de datos por hilo para CRT.

La ventaja de usar _beginthread*es que sus llamadas CRT desde el hilo funcionarán correctamente.

Debería usar _beginthreado _beginthreadexpermitir que la biblioteca de tiempo de ejecución C haga su propia inicialización del hilo. Solo los programadores de C / C ++ necesitan saber esto, ya que ahora deberían conocer las reglas de uso de su propio entorno de desarrollo.

Si lo usa _beginthread, no necesita llamar, CloseHandleya que RTL lo hará por usted. Es por eso que no puede esperar en el mango si lo ha usado _beginthread. También _beginthreadconduce a la confusión si la función de subproceso sale inmediatamente (rápidamente) ya que el subproceso de inicio puede quedar sosteniendo un identificador de subproceso no válido para el subproceso que acaba de iniciar.

_beginthreadexlos identificadores se pueden usar para esperar pero también requieren una llamada explícita a CloseHandle. Esto es parte de lo que los hace seguros para usar con wait. Otro problema para que sea completamente infalible es siempre iniciar el hilo suspendido. Verifique el éxito, identificador de registro, etc. El hilo de reanudar. Esto es necesario para evitar que un subproceso termine antes de que el subproceso de inicio pueda grabar su identificador.

La mejor práctica es usar _beginthreadex, comenzar a suspender y luego reanudar después de grabar el identificador, esperar en el identificador está bien, CloseHandledebe llamarse

CreateThread()solía tener pérdidas de memoria cuando utiliza funciones CRT en su código. _beginthreadex()tiene los mismos parámetros que CreateThread()y es más versátil que _beginthread(). Así que te recomiendo que uses _beginthreadex().

Con respecto a su pregunta actualizada: "También he leído en un par de lugares a los que no puedo llamar WaitForSingleObject()si los usaba _beginthread(), pero si llamo _endthread()en el hilo, ¿no debería funcionar?"

En general, puede pasar un identificador de subproceso a WaitForSingleObject()(u otras API que esperan en los identificadores de objeto) para bloquear hasta que el subproceso se haya completado. Pero el identificador de subproceso creado por _beginthread()se cierra cuando _endthread()se llama (lo que se puede hacer explícitamente o implícitamente por el tiempo de ejecución cuando vuelve el procedimiento de subproceso).

El problema se menciona en la documentación para WaitForSingleObject():

Si este identificador está cerrado mientras la espera aún está pendiente, el comportamiento de la función no está definido.

En cuanto a las firmas de funciones, CreateThreades casi idéntico a _beginthreadex.

_beginthread,_beginthreadx vsCreateThread

HANDLE WINAPI CreateThread(
  __in_opt   LPSECURITY_ATTRIBUTES lpThreadAttributes,
  __in       SIZE_T dwStackSize,
  __in       LPTHREAD_START_ROUTINE lpStartAddress,
  __in_opt   LPVOID lpParameter,
  __in       DWORD dwCreationFlags,
  __out_opt  LPDWORD lpThreadId
);

uintptr_t _beginthread( 
   void( *start_address )( void * ),
   unsigned stack_size,
   void *arglist 
);

uintptr_t _beginthreadex( 
   void *security,
   unsigned stack_size,
   unsigned ( *start_address )( void * ),
   void *arglist,
   unsigned initflag,
   unsigned *thrdaddr 
);

Los comentarios aquí indicados _beginthreadpueden usar una convención __cdeclo una __clrcallllamada como punto de inicio, y _beginthreadexpueden usar cualquiera __stdcallo __clrcallpara el punto de inicio.

Creo que cualquier comentario que la gente haya hecho sobre las pérdidas de memoria CreateThreadtiene más de una década y probablemente debería ignorarse.

Curiosamente, ambas _beginthread*funciones en realidad llaman CreateThreadbajo el capó, en C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\crt\srcmi máquina.

// From ~line 180 of beginthreadex.c
/*
 * Create the new thread using the parameters supplied by the caller.
 */
if ( (thdl = (uintptr_t)
      CreateThread( (LPSECURITY_ATTRIBUTES)security,
                    stacksize,
                    _threadstartex,
                    (LPVOID)ptd,
                    createflag,
                    (LPDWORD)thrdaddr))
         == (uintptr_t)0 )
{
        err = GetLastError();
        goto error_return;
}

beginthreadexte da un hilo HANDLEpara usar en WaitForSingleObjecty amigos. beginthreadno lo hace No olvides CloseHandle()cuando hayas terminado. La respuesta real sería usar boost::threado pronto la clase de hilo de C ++ 09.

En comparación con _beginthread, con _beginthreadexusted puede:

1. Especificar atributos de seguridad.
2. Comience un hilo en estado suspendido.
3. Puede obtener la identificación del hilo que se puede usar con OpenThread.
4. Se garantiza que el identificador de hilo devuelto sea válido si la llamada fue exitosa. Hay que cerrar el asa con CloseHandle.
5. El identificador de subproceso devuelto se puede usar con las API de sincronización.

El _beginthreadexse parece mucho CreateThread, pero el primero es una implementación de CRT y el segundo una llamada a la API de Windows. La documentación para CreateThread contiene la siguiente recomendación:

Un subproceso en un ejecutable que llama a la biblioteca de tiempo de ejecución C (CRT) debe usar las funciones _beginthreadexy _endthreadexpara la gestión de subprocesos en lugar de CreateThready ExitThread; Esto requiere el uso de la versión multiproceso del CRT. Si un subproceso creado utilizando CreateThreadllama a la CRT, la CRT puede finalizar el proceso en condiciones de poca memoria.

CreateThread()una vez fue un no-no porque el CRT se inicializaría / limpiaría incorrectamente. Pero esto ahora es historia: ahora se puede (usando VS2010 y probablemente algunas versiones anteriores) llamar CreateThread()sin romper el CRT.

Aquí está la confirmación oficial de MS . Establece una excepción:

En realidad, la única función que no debe usarse en un hilo creado con CreateThread()es la signal()función.

Sin embargo, desde el punto de vista de la consistencia, personalmente prefiero seguir usando _beginthreadex().

CreateThread()es la llamada a la API de Windows que es neutral al lenguaje. Simplemente crea un objeto OS - thread y devuelve HANDLE a este thread. Todas las aplicaciones de Windows están utilizando esta llamada para crear hilos. Todos los idiomas evitan las llamadas directas a la API por razones obvias: 1. No desea que su código sea específico del sistema operativo 2. Debe realizar algunas tareas de mantenimiento antes de llamar a API: convertir parámetros y resultados, asignar almacenamiento temporal, etc.

_beginthreadex()es la envoltura de C CreateThread()que da cuenta de C específica. Permite que los F-ns de un solo subproceso original funcionen en un entorno multiproceso al asignar almacenamiento específico de subproceso.

Si no usa CRT, no puede evitar una llamada directa CreateThread(). Si usa CRT, debe usar _beginthreadex()o algunas cadenas de CRT f-ns pueden no funcionar correctamente antes de VC2005.

CreateThread()es la llamada directa al sistema. Está implementado en el Kernel32.dllcual, muy probablemente, su aplicación ya estará vinculada por otras razones. Siempre está disponible en los sistemas modernos de Windows.

_beginthread()y _beginthreadex()son funciones de contenedor en Microsoft C Runtime ( msvcrt.dll). Las diferencias entre las dos llamadas se indican en la documentación. Por lo tanto, está disponible cuando Microsoft C Runtime está disponible, o si su aplicación está vinculada estáticamente con ella. Es probable que también se vincule con esa biblioteca, a menos que esté codificando en la API de Windows pura (como lo hago personalmente a menudo).

Su pregunta es coherente y en realidad recurrente. Como muchas API, hay una funcionalidad duplicada y ambigua en la API de Windows con la que tenemos que lidiar. Lo peor de todo, la documentación no aclara el problema. Supongo que la _beginthread()familia de funciones se creó para una mejor integración con otras funcionalidades C estándar, como la manipulación de errno. _beginthread()así se integra mejor con el tiempo de ejecución de C.

A pesar de eso, a menos que tenga buenas razones para usar _beginthread()o _beginthreadex(), debe usarlo CreateThread(), principalmente porque podría obtener una dependencia de biblioteca menos en su ejecutable final (y para MS CRT esto importa un poco). Tampoco tiene un código de ajuste alrededor de la llamada, aunque este efecto es insignificante. En otras palabras, creo que la razón principal para seguir CreateThread()es que no hay una buena razón _beginthreadex()para comenzar. Las funcionalidades son precisamente, o casi, las mismas.

Una buena razón para usar _beginthread() sería (ya que parece ser falso) que los objetos C ++ se desenrollarían / ​​destruirían adecuadamente si _endthread()se llamara.

Las otras respuestas no discuten las implicaciones de llamar a una función de tiempo de ejecución C que envuelve una función API Win32. Esto es importante cuando se considera el comportamiento de bloqueo del cargador de DLL.

Ya sea que se _beginthread{ex}administre o no una gestión especial de memoria de fibra / hilo de tiempo de ejecución de C, como se analiza en las otras respuestas, se implementa en (suponiendo un enlace dinámico al tiempo de ejecución de C) una DLL que los procesos pueden no haberse cargado todavía.

No es seguro llamar _beginthread*desde DllMain. He probado esto escribiendo una DLL cargada usando la función "AppInit_DLLs" de Windows. Llamar en _beginthreadex (...)lugar de CreateThread (...)provocar que MUCHAS partes importantes de Windows dejen de funcionar durante el arranque como los DllMainpuntos muertos de punto de entrada que esperan que se libere el bloqueo del cargador para realizar ciertas tareas de inicialización.

Por cierto, esta es también la razón por la que kernel32.dll tiene muchas funciones de cadena superpuestas que también tiene el tiempo de ejecución de C: úselas DllMainpara evitar el mismo tipo de situación.

Si lees el libro Depuración de aplicaciones de Windows de Jeffrey Richter, explica que casi en todos los casos debes llamar en _beginthreadexlugar de llamar CreateThread. _beginthreades solo un contenedor simplificado _beginthreadex.

_beginthreadexinicializa ciertas partes internas de CRT (C RunTime) que la CreateThreadAPI no haría.

Una consecuencia si usa la CreateThreadAPI en lugar de usar _begingthreadexllamadas a funciones CRT podría causar problemas inesperados.

Echa un vistazo a este viejo Microsoft Journal de Richter.

Ya no hay diferencia entre los dos.

Todos los comentarios sobre pérdidas de memoria, etc. se basan en versiones muy antiguas de <VS2005. He hecho algunas pruebas de estrés hace años y podría desacreditar este mito. Incluso Microsoft mezcla los estilos en sus ejemplos, casi nunca usa _beginthread.