Filetage Windows: _beginthread vs _beginthreadex vs CreateThread C ++

Quelle est la meilleure façon de démarrer un fil _beginthread, _beginthreadxou CreateThread?

J'essaie de déterminer quels sont les avantages / inconvénients de _beginthread, _beginthreadexet CreateThread. Toutes ces fonctions renvoient un descripteur de thread à un thread nouvellement créé, je sais déjà que CreateThread fournit un peu d'informations supplémentaires lorsqu'une erreur se produit (cela peut être vérifié en appelant GetLastError) ... mais que dois-je prendre en compte lorsque je ' m en utilisant ces fonctions?

Je travaille avec une application Windows, donc la compatibilité multiplateforme est déjà hors de question.

J'ai parcouru la documentation msdn et je ne peux tout simplement pas comprendre, par exemple, pourquoi quelqu'un déciderait d'utiliser _beginthread au lieu de CreateThread ou vice versa.

À votre santé!

Mise à jour: OK, merci pour toutes les informations, j'ai également lu dans quelques endroits que je ne peux pas appeler WaitForSingleObject()si j'ai utilisé _beginthread(), mais si j'appelle _endthread()dans le fil de discussion, cela ne devrait-il pas fonctionner? Quel est le problème là-bas?

CreateThread() est un appel API Win32 brut pour créer un autre thread de contrôle au niveau du noyau.

_beginthread()& _beginthreadex()sont des appels de bibliothèque d'exécution C qui appellent CreateThread()dans les coulisses. Une fois CreateThread()retourné, _beginthread/ex()s'occupe de la comptabilité supplémentaire pour rendre la bibliothèque d'exécution C utilisable et cohérente dans le nouveau thread.

En C ++, vous devriez certainement utiliser à _beginthreadex()moins que vous ne fassiez pas du tout de lien vers la bibliothèque d'exécution C (aka MSVCRT * .dll / .lib).

Il existe plusieurs différences entre _beginthread()et _beginthreadex(). _beginthreadex()a été fait pour agir plus comme CreateThread()(dans les deux paramètres et comment il se comporte).

Comme Drew Hall le mentionne, si vous utilisez le runtime C / C ++, vous devez utiliser _beginthread()/ _beginthreadex()au lieu de CreateThread()pour que le runtime ait une chance d'effectuer sa propre initialisation de thread (configuration du stockage local des threads, etc.).

En pratique, cela signifie que cela CreateThread()ne devrait pratiquement jamais être utilisé directement par votre code.

Les documents MSDN pour _beginthread()/ _beginthreadex()ont pas mal de détails sur les différences - l'une des plus importantes est que puisque le handle de thread pour un thread créé par _beginthread()se ferme automatiquement par le CRT lorsque le thread se termine, "si le thread généré par _beginthread se termine rapidement, le handle retourné à l'appelant de _beginthread peut être invalide ou, pire, pointer vers un autre thread ".

Voici ce que _beginthreadex()disent les commentaires dans la source 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).

Mise à jour de janvier 2013:

Le CRT pour VS 2012 a un bit supplémentaire d'initialisation effectué dans _beginthreadex(): si le processus est une "application packagée" (si quelque chose d'utile est renvoyé GetCurrentPackageId()), le runtime initialisera le MTA sur le thread nouvellement créé.

En général, la bonne chose à faire est d'appeler _beginthread()/_endthread()(ou les ex()variantes). Toutefois, si vous utilisez le CRT en tant que .dll, l'état CRT sera correctement initialisé et détruit comme le CRT DllMainsera appelé avec DLL_THREAD_ATTACHet DLL_THREAD_DETACHlors de l'appel CreateThread()et ExitThread()ou du retour, respectivement.

Le DllMaincode du CRT se trouve dans le répertoire d'installation de VS sous VC \ crt \ src \ crtlib.c.

C'est le code au cœur de _beginthreadex(voir 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;
    }

Le reste _beginthreadexinitialise la structure de données par thread pour CRT.

L'avantage de l'utilisation _beginthread*est que vos appels CRT à partir de thread fonctionneront correctement.

Vous devez utiliser _beginthreadou _beginthreadexpour permettre à la bibliothèque d'exécution C de faire sa propre initialisation du thread. Seuls les programmeurs C / C ++ ont besoin de le savoir car ils devraient désormais connaître les règles d'utilisation de leur propre environnement de développement.

Si vous utilisez, _beginthreadvous n'avez pas besoin d'appeler CloseHandlecomme le RTL le fera pour vous. C'est pourquoi vous ne pouvez pas attendre sur la poignée si vous avez utilisé _beginthread. Conduit également _beginthreadà la confusion si la fonction de thread se termine immédiatement (rapidement) car le thread de lancement peut être laissé avec une poignée de thread non valide pour le thread qu'il vient de lancer.

_beginthreadexles handles peuvent être utilisés pour wait mais nécessitent également un appel explicite à CloseHandle. Cela fait partie de ce qui les rend sûrs pour une utilisation avec attente. Il y a un autre problème pour le rendre complètement infaillible est de toujours démarrer le thread suspendu. Vérifiez le succès, enregistrez la poignée, etc. Cela est nécessaire pour empêcher un thread de se terminer avant que le thread de lancement puisse enregistrer son handle.

La meilleure pratique consiste à utiliser _beginthreadex, démarrer suspendu puis reprendre après l'enregistrement de la poignée, attendre que la poignée est OK, CloseHandledoit être appelée.

CreateThread()utilisé pour avoir des fuites de mémoire lorsque vous utilisez des fonctions CRT dans votre code. _beginthreadex()a les mêmes paramètres que CreateThread()et il est plus polyvalent que _beginthread(). Je vous recommande donc d'utiliser _beginthreadex().

En ce qui concerne votre question mise à jour: "J'ai également lu dans quelques endroits que je ne peux pas appeler WaitForSingleObject()si j'ai utilisé _beginthread(), mais si j'appelle _endthread()dans le fil de discussion, cela ne devrait-il pas fonctionner?"

En général, vous pouvez passer un handle de thread à WaitForSingleObject()(ou à d'autres API qui attendent sur les handles d'objet) pour bloquer jusqu'à ce que le thread soit terminé. Mais le handle de thread créé par _beginthread()est fermé lorsqu'il _endthread()est appelé (ce qui peut être fait explicitement ou est fait implicitement par le moment de l'exécution lorsque la procédure de thread retourne).

Le problème est signalé dans la documentation pour WaitForSingleObject():

Si ce handle est fermé alors que l'attente est toujours en attente, le comportement de la fonction n'est pas défini.

En regardant les signatures de fonction, CreateThreadest presque identique à _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 
);

Les remarques ici indiquent que vous _beginthreadpouvez utiliser la convention soit __cdeclou __clrcallappeler comme point de départ, et _beginthreadexpeut utiliser soit __stdcallou __clrcallcomme point de départ.

Je pense que tous les commentaires des gens sur les fuites de mémoire datent de CreateThreadplus d'une décennie et devraient probablement être ignorés.

Fait intéressant, les deux _beginthread*fonctions appellent CreateThreadsous le capot, C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\crt\srcsur ma machine.

// 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;
}

beginthreadexvous donne un fil HANDLEà utiliser dans WaitForSingleObjectet vos amis. beginthreadpas. N'oubliez pas de CloseHandle()quand vous avez terminé. La vraie réponse serait d'utiliser boost::threadou bientôt la classe de thread de C ++ 09.

Par rapport à _beginthread, avec _beginthreadexvous pouvez:

1. Spécifiez les attributs de sécurité.
2. Démarrez un thread à l'état suspendu.
3. Vous pouvez obtenir l'ID de thread qui peut être utilisé avec OpenThread.
4. Le descripteur de thread renvoyé est garanti valide si l'appel a réussi. Là, vous devez fermer la poignée avec CloseHandle.
5. Le descripteur de thread renvoyé peut être utilisé avec les API de synchronisation.

Le _beginthreadexressemble beaucoup CreateThread, mais le premier est une implémentation CRT et le second un appel d'API Windows. La documentation de CreateThread contient la recommandation suivante:

Un thread dans un exécutable qui appelle la bibliothèque d'exécution C (CRT) doit utiliser les fonctions _beginthreadexet _endthreadexpour la gestion des threads plutôt que CreateThreadet ExitThread; cela nécessite l'utilisation de la version multithread du CRT. Si un thread créé à l'aide d' CreateThreadappels le CRT, le CRT peut terminer le processus dans des conditions de mémoire insuffisante.

CreateThread()une fois était un non-non parce que le CRT serait incorrectement initialisé / nettoyé. Mais c'est maintenant de l'histoire: on peut maintenant (en utilisant VS2010 et probablement quelques versions en arrière) appeler CreateThread()sans casser le CRT.

Voici la confirmation officielle de MS . Il énonce une exception:

En fait, la seule fonction qui ne doit pas être utilisée dans un thread créé avec CreateThread()est la signal()fonction.

Cependant, du point de vue de la cohérence, je préfère personnellement continuer à utiliser _beginthreadex().

CreateThread()est un appel d'API Windows indépendant du langage. Il crée simplement un objet OS - thread et renvoie HANDLE à ce thread. Toutes les applications Windows utilisent cet appel pour créer des threads. Tous les langages évitent les appels d'API directs pour des raisons évidentes: 1. Vous ne voulez pas que votre code soit spécifique au système d'exploitation 2. Vous devez faire quelques tâches ménagères avant d'appeler API: convertir les paramètres et les résultats, allouer un stockage temporaire, etc.

_beginthreadex()est un wrapper C CreateThread()qui tient compte du C spécifique. Il permet aux C f-ns à thread unique d'origine de travailler dans un environnement multithread en allouant un stockage spécifique au thread.

Si vous n'utilisez pas CRT, vous ne pouvez pas éviter un appel direct à CreateThread(). Si vous utilisez CRT, vous devez utiliser _beginthreadex()ou certaines chaînes CRT f-ns peuvent ne pas fonctionner correctement avant VC2005.

CreateThread()est l'appel système direct. Il est implémenté sur Kernel32.dlllequel, très probablement, votre application sera déjà liée pour d'autres raisons. Il est toujours disponible dans les systèmes Windows modernes.

_beginthread()et _beginthreadex()sont des fonctions wrapper dans Microsoft C Runtime ( msvcrt.dll). Les différences entre les deux appels sont indiquées dans la documentation. Il est donc disponible lorsque le Microsoft C Runtime est disponible, ou si votre application est liée statiquement à celui-ci. Vous serez probablement lié à cette bibliothèque, à moins que vous ne codiez dans l'API Windows pure (comme je le fais souvent personnellement).

Votre question est cohérente et en fait récurrente. Comme de nombreuses API, il existe des fonctionnalités dupliquées et ambiguës dans l'API Windows avec lesquelles nous devons faire face. Pire encore, la documentation ne clarifie pas le problème. Je suppose que la _beginthread()famille de fonctions a été créée pour une meilleure intégration avec d'autres fonctionnalités C standard, telles que la manipulation de errno. _beginthread()s'intègre ainsi mieux avec le runtime C.

Malgré cela, à moins que vous n'ayez de bonnes raisons d'utiliser _beginthread()ou _beginthreadex(), vous devriez utiliser CreateThread(), principalement parce que vous pourriez avoir une dépendance de bibliothèque en moins dans votre exécutable final (et pour MS CRT, cela a un peu d'importance). Vous n'avez pas non plus de code d'encapsulation autour de l'appel, bien que cet effet soit négligeable. En d'autres termes, je pense que la principale raison de s'en tenir CreateThread()est qu'il n'y a pas de bonne raison d'utiliser _beginthreadex()pour commencer. Les fonctionnalités sont exactement, ou presque, les mêmes.

Une bonne raison d'utiliser _beginthread() serait (car cela semble être faux) que les objets C ++ seraient correctement déroulés / détruits s'ils _endthread()étaient appelés.

Les autres réponses n'abordent pas les implications de l'appel d'une fonction d'exécution C qui encapsule une fonction API Win32. Ceci est important lors de l'examen du comportement de verrouillage du chargeur DLL.

Que ce soit ou non _beginthread{ex}une gestion spéciale de la mémoire thread / fibre C Runtime comme le discutent les autres réponses, elle est implémentée dans (en supposant une liaison dynamique avec le run-time C) une DLL que les processus n'ont peut-être pas encore chargée.

Il n'est pas sûr d'appeler _beginthread*depuis DllMain. J'ai testé cela en écrivant une DLL chargée à l'aide de la fonction Windows "AppInit_DLLs". L'appel _beginthreadex (...)au lieu de CreateThread (...)fait que BEAUCOUP de parties importantes de Windows cessent de fonctionner pendant le démarrage, car les DllMainblocages de point d'entrée attendent que le verrou du chargeur soit libéré afin d'effectuer certaines tâches d'initialisation.

Incidemment, c'est aussi pourquoi kernel32.dll a beaucoup de fonctions de chaîne qui se chevauchent que le run-time C fait également - utilisez celles de DllMainpour éviter le même genre de situation.

Si vous lisez le livre Debugging Windows Application From Jeffrey Richter, il explique que presque dans tous les cas, vous devez appeler _beginthreadexau lieu d'appeler CreateThread. _beginthreadest juste un wrapper simplifié _beginthreadex.

_beginthreadexinitialise certains composants internes CRT (C RunTime) que l' CreateThreadAPI ne ferait pas.

Une conséquence si vous utilisez l' CreateThreadAPI au lieu d'utiliser des _begingthreadexappels aux fonctions CRT peut provoquer des problèmes inattendus.

Consultez cet ancien Microsoft Journal de Richter.

Il n'y a plus de différence entre les deux.

Tous les commentaires sur les fuites de mémoire, etc. sont basés sur des versions <VS2005 très anciennes. J'ai fait des tests de résistance il y a des années et pourrais démystifier ce mythe. Même Microsoft mélange les styles dans leurs exemples, n'utilisant presque jamais _beginthread.