Wątki w systemie Windows: _beginthread vs _beginthreadex vs CreateThread C ++

Jaki jest lepszy sposób na rozpoczęcie wątku _beginthread, _beginthreadxczy CreateThread?

Próbuję ustalić, jakie są zalety / wady _beginthread, _beginthreadexi CreateThread. Wszystkie te funkcje zwracają uchwyt wątku do nowo utworzonego wątku, już wiem, że CreateThread dostarcza trochę dodatkowych informacji, gdy wystąpi błąd (można to sprawdzić, wywołując GetLastError) ... ale jakie są rzeczy, które powinienem rozważyć, kiedy ja ' korzystam z tych funkcji?

Pracuję z aplikacją Windows, więc kompatybilność między platformami jest już wykluczona.

Przejrzałem dokumentację msdn i po prostu nie rozumiem, na przykład, dlaczego ktoś miałby zdecydować się na użycie _beginthread zamiast CreateThread lub odwrotnie.

Twoje zdrowie!

Aktualizacja: OK, dzięki za wszystkie informacje, przeczytałem też w kilku miejscach, do których nie mogę zadzwonić, WaitForSingleObject()gdybym korzystał _beginthread(), ale jeśli dzwonię _endthread()w wątku, czy to nie powinno działać? O co tam chodzi?

CreateThread() to surowe wywołanie API Win32 do tworzenia kolejnego wątku kontroli na poziomie jądra.

_beginthread()& _beginthreadex()to wywołania biblioteki wykonawczej C, które wywołują CreateThread()za kulisami. Po CreateThread()powrocie _beginthread/ex()zajmuje się dodatkową księgowością, aby biblioteka środowiska wykonawczego C była użyteczna i spójna w nowym wątku.

W C ++ prawie na pewno powinieneś używać, _beginthreadex()chyba że w ogóle nie będziesz łączyć się z biblioteką wykonawczą C (aka MSVCRT * .dll / .lib).

Istnieje kilka różnic między _beginthread()i _beginthreadex(). _beginthreadex()został stworzony, aby zachowywać się bardziej podobnie CreateThread()(zarówno pod względem parametrów, jak i zachowania).

Jak wspomina Drew Hall , jeśli używasz środowiska uruchomieniowego C / C ++, musisz użyć _beginthread()/ _beginthreadex()zamiast, CreateThread()aby środowisko wykonawcze miało szansę na wykonanie własnej inicjalizacji wątku (ustawienie lokalnego magazynu wątku itp.).

W praktyce oznacza to, że CreateThread()prawie nigdy nie powinno być używane bezpośrednio w kodzie.

Dokumenty MSDN dla _beginthread()/ _beginthreadex()zawierają sporo szczegółów na temat różnic - jednym z ważniejszych jest to, że ponieważ uchwyt wątku dla wątku utworzonego przez _beginthread()jest automatycznie zamykany przez CRT po zakończeniu wątku, „jeśli wątek wygenerowany przez _beginthread kończy działanie szybko uchwyt zwrócony do obiektu wywołującego _beginthread może być nieprawidłowy lub, co gorsza, wskazywać na inny wątek ".

Oto, co _beginthreadex()mają do powiedzenia komentarze w źródle 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).

Aktualizacja styczeń 2013:

CRT dla VS 2012 ma dodatkowy bit inicjalizacji wykonywany w _beginthreadex(): jeśli proces jest „spakowaną aplikacją” (jeśli zwracane jest coś użytecznego GetCurrentPackageId()), środowisko wykonawcze zainicjuje MTA w nowo utworzonym wątku.

Ogólnie rzecz biorąc, właściwą rzeczą do zrobienia jest wywołanie _beginthread()/_endthread()(lub ex()warianty). Jeśli jednak użyjesz CRT jako pliku dll, stan CRT zostanie poprawnie zainicjowany i zniszczony, gdy CRT DllMainzostanie wywołany odpowiednio z DLL_THREAD_ATTACHi DLL_THREAD_DETACHpodczas wywoływania CreateThread()i ExitThread()lub powrotu.

DllMainKod na CRT można znaleźć w katalogu instalacyjnym VS pod VC \ crt \ src \ crtlib.c.

To jest kod leżący u podstaw _beginthreadex(zobacz 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;
    }

Reszta _beginthreadexinicjuje strukturę danych na wątek dla CRT.

Zaletą używania _beginthread*jest to, że wywołania CRT z wątku będą działać poprawnie.

Powinieneś użyć _beginthreadlub, _beginthreadexaby pozwolić bibliotece wykonawczej C na wykonanie własnej inicjalizacji wątku. Tylko programiści C / C ++ muszą to wiedzieć, ponieważ powinni teraz znać zasady korzystania z własnego środowiska programistycznego.

Jeśli używasz _beginthread, nie musisz dzwonić, CloseHandleponieważ RTL zrobi to za Ciebie. Dlatego nie możesz czekać na uchwycie, jeśli użyłeś _beginthread. _beginthreadProwadzi również do zamieszania, jeśli funkcja wątku kończy pracę natychmiast (szybko), ponieważ wątek uruchamiający może pozostać z nieprawidłowym uchwytem wątku do wątku, który właśnie uruchomił.

_beginthreadexuchwyty mogą służyć do oczekiwania, ale wymagają również jawnego wywołania CloseHandle. Jest to część tego, co sprawia, że ​​można ich bezpiecznie używać z czekaniem. Innym problemem, który sprawia, że ​​jest całkowicie niezawodny, jest zawsze rozpoczynanie zawieszonego wątku. Sprawdź powodzenie, uchwyt rekordu itp. Wątek wznowienia. Jest to wymagane, aby zapobiec zakończeniu wątku, zanim wątek uruchamiający będzie mógł zarejestrować swój uchwyt.

Najlepszą praktyką jest użycie _beginthreadex, rozpoczęcie zawieszenia, a następnie wznowienie po nagraniu uchwytu, oczekiwanie na uchwyt jest OK, CloseHandlemusi zostać wywołane.

CreateThread()kiedyś występowały przecieki pamięci podczas używania funkcji CRT w kodzie. _beginthreadex()ma takie same parametry jak CreateThread()i jest bardziej wszechstronny niż _beginthread(). Więc polecam ci użycie _beginthreadex().

Odnosząc się do twojego zaktualizowanego pytania: „Czytałem też w kilku miejscach, do których nie mogę zadzwonić, WaitForSingleObject()jeśli użyłem _beginthread(), ale jeśli dzwonię _endthread()w wątku, czy to nie powinno działać?”

Ogólnie rzecz biorąc, można przekazać uchwyt wątku do WaitForSingleObject()(lub inne interfejsy API, które czekają na uchwyty obiektów), aby blokować do momentu zakończenia wątku. Ale uchwyt wątku utworzony przez _beginthread()jest zamykany, gdy _endthread()jest wywoływany (co można zrobić jawnie lub niejawnie przez czas wykonywania, gdy procedura wątku zwraca).

Problem pojawia się w dokumentacji WaitForSingleObject():

Jeśli ten uchwyt zostanie zamknięty, gdy oczekiwanie jest nadal w toku, zachowanie funkcji jest niezdefiniowane.

Patrząc na sygnatury funkcji, CreateThreadjest prawie identyczny z _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 
);

Uwagi na temat tutaj mówią , że _beginthreadmożna użyć konwencji wywoływania albo __cdecllub __clrcalljako punktu początkowego, a jako punktu początkowego _beginthreadexmożna użyć albo __stdcallalbo __clrcall.

Myślę, że wszelkie komentarze ludzi na temat wycieków pamięci CreateThreadmają ponad dekadę i prawdopodobnie powinny zostać zignorowane.

Co ciekawe, obie _beginthread*funkcje faktycznie wywołują CreateThreadpod maską, w C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\crt\srcmoim komputerze.

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

beginthreadexdaje ci wątek HANDLEdo wykorzystania w WaitForSingleObjecti znajomych. beginthreadnie. Nie zapomnij, CloseHandle()kiedy skończysz. Prawdziwą odpowiedzią byłoby użycie boost::threadlub wkrótce C ++ 09 klasy wątku.

W porównaniu _beginthreadz _beginthreadex, możesz:

1. Określ atrybuty zabezpieczeń.
2. Rozpocznij wątek w stanie zawieszonym.
3. Możesz uzyskać identyfikator wątku, którego można używać z OpenThread.
4. Zwrócony uchwyt wątku jest gwarantowany, jeśli wywołanie zakończyło się pomyślnie. Tam musisz zamknąć uchwyt CloseHandle.
5. Zwrócony uchwyt wątku może być używany z synchronizacyjnymi interfejsami API.

To _beginthreadexbardzo przypomina CreateThread, ale pierwsza to implementacja CRT, a druga wywołanie Windows API. Dokumentacja narzędzia CreateThread zawiera następujące zalecenia:

Wątek w pliku wykonywalnym, który wywołuje bibliotekę wykonawczą języka C (CRT), powinien używać funkcji _beginthreadexi _endthreadexdo zarządzania wątkami, a nie CreateThreadi ExitThread; wymaga to użycia wielowątkowej wersji CRT. Jeśli wątek utworzony przy użyciu CreateThreadwywołań CRT, CRT może zakończyć proces w warunkach małej ilości pamięci.

CreateThread()kiedyś było nie-nie, ponieważ CRT byłby nieprawidłowo inicjowany / czyszczony. Ale to już historia: można teraz (używając VS2010 i prawdopodobnie kilku wersji wstecz) dzwonić CreateThread()bez zrywania CRT.

Oto oficjalne potwierdzenie MS . Stanowi jeden wyjątek:

Właściwie jedyną funkcją, której nie należy używać w wątku utworzonym za pomocą, CreateThread()jest signal()funkcja.

Jednak z punktu widzenia spójności osobiście wolę nadal używać _beginthreadex().

CreateThread()to wywołanie interfejsu API systemu Windows, które jest neutralne językowo. Po prostu tworzy obiekt systemu operacyjnego - wątek i zwraca HANDLE do tego wątku. Wszystkie aplikacje systemu Windows używają tego wywołania do tworzenia wątków. Wszystkie języki unikają bezpośredniego wywołania API z oczywistych powodów: 1. Nie chcesz, aby Twój kod był specyficzny dla systemu operacyjnego 2. Przed wywołaniem interfejsu API musisz wykonać pewne czynności konserwacyjne: przekonwertować parametry i wyniki, przydzielić tymczasową pamięć itp.

_beginthreadex()jest opakowaniem C, CreateThread()które jest specyficzne dla języka C. Umożliwia pracę oryginalnych jednowątkowych C f-ns w środowisku wielowątkowym poprzez przydzielanie pamięci specyficznej dla wątku.

Jeśli nie używasz CRT, nie możesz uniknąć bezpośredniego połączenia CreateThread(). Jeśli używasz CRT, musisz użyć _beginthreadex()lub niektóre f-ns z ciągiem CRT mogą nie działać poprawnie przed VC2005.

CreateThread()jest prostym wywołaniem systemowym. Jest zaimplementowany, na Kernel32.dllktórym najprawdopodobniej Twoja aplikacja będzie już połączona z innymi powodami. Jest zawsze dostępny w nowoczesnych systemach Windows.

_beginthread()i _beginthreadex()są funkcjami opakowania w Microsoft C Runtime ( msvcrt.dll). Różnice między tymi dwoma zaproszeniami są opisane w dokumentacji. Jest zatem dostępny, gdy środowisko wykonawcze języka Microsoft C jest dostępne lub jeśli aplikacja jest z nim połączona statycznie. Prawdopodobnie będziesz również łączyć się z tą biblioteką, chyba że kodujesz w czystym interfejsie API systemu Windows (co osobiście często robię).

Twoje pytanie jest spójne i faktycznie powracające. Podobnie jak wiele interfejsów API, mamy do czynienia z zduplikowanymi i niejednoznacznymi funkcjami w interfejsie Windows API. Co najgorsze, dokumentacja nie wyjaśnia sprawy. Przypuszczam, że _beginthread()rodzina funkcji została stworzona w celu lepszej integracji z innymi standardowymi funkcjami C, takimi jak manipulacja errno. _beginthread()dzięki temu lepiej integruje się ze środowiskiem wykonawczym C.

Mimo to, chyba że masz dobre powody, aby używać _beginthread()lub _beginthreadex(), powinieneś używać CreateThread(), głównie dlatego, że możesz uzyskać jedną zależność od biblioteki mniej w swoim ostatecznym pliku wykonywalnym (a dla MS CRT ma to trochę znaczenia). Nie masz również zawijającego się kodu wokół wywołania, chociaż ten efekt jest pomijalny. Innymi słowy, uważam, że głównym powodem, dla CreateThread()którego warto się trzymać, jest to, że nie ma dobrego powodu, _beginthreadex()aby zacząć od tego. Funkcjonalności są dokładnie lub prawie takie same.

Jednym z dobrych powodów użycia _beginthread() byłoby (jak się wydaje fałszywe), że obiekty C ++ byłyby prawidłowo rozwijane / niszczone, gdyby _endthread()zostały wywołane.

Inne odpowiedzi nie omawiają konsekwencji wywołania funkcji czasu wykonywania C, która otacza funkcję API Win32. Jest to ważne przy rozważaniu sposobu blokowania modułu ładującego DLL.

Niezależnie od tego, czy _beginthread{ex}jakikolwiek specjalny sposób zarządzania pamięcią wątków / światłowodów środowiska wykonawczego języka C, o którym mowa w innych odpowiedziach, jest zaimplementowany w (zakładając dynamiczne łączenie z programem C Runtime) w bibliotece DLL, której procesy mogły jeszcze nie zostać załadowane.

To nie jest bezpieczne, aby zadzwonić _beginthread*z DllMain. Przetestowałem to, pisząc bibliotekę DLL załadowaną przy użyciu funkcji „AppInit_DLLs” systemu Windows. Wywołanie _beginthreadex (...)zamiast CreateThread (...)powoduje, że WIELE ważnych części systemu Windows przestaje działać podczas rozruchu jako DllMainzakleszczenie punktu wejścia, czekające na zwolnienie blokady modułu ładującego w celu wykonania pewnych zadań inicjalizacyjnych.

Nawiasem mówiąc, jest to również powód, dla którego kernel32.dll ma wiele nakładających się funkcji tekstowych, które ma również środowisko wykonawcze C - użyj tych z, DllMainaby uniknąć tego samego rodzaju sytuacji.

Jeśli przeczytasz w niej książkę Debugowanie aplikacji systemu Windows od Jeffreya Richtera, wyjaśnia on, że prawie we wszystkich przypadkach musisz dzwonić _beginthreadexzamiast dzwonić CreateThread. _beginthreadto tylko uproszczone opakowanie _beginthreadex.

_beginthreadexinicjuje pewne wewnętrzne funkcje CRT (C RunTime), których CreateThreadinterfejs API nie zrobiłby.

Konsekwencją korzystania z CreateThreadinterfejsu API zamiast używania _begingthreadexwywołań funkcji CRT może być nieoczekiwana przyczyna problemów.

Sprawdź ten stary Microsoft Journal od Richtera.

Powinieneś wypróbować ten kod

#include<stdio.h>
#include<stdlib.h>
#include<windows.h>
#include<process.h>

UINT __stdcall Staff(PVOID lp){
 printf("The Number is %d\n", GetCurrentThreadId());
 return 0;
}

INT main(INT argc, PCHAR argv[])
{

    const INT Staff_Number = 5;
    HANDLE hd[Staff_Number];
    for(INT i=0; i < Staff_Number; i++){
       hd[i] = (HANDLE)_beginthreadex(NULL, 0, Staff, NULL, 0, NULL);
    }

 WaitForMultipleObjects(Staff_Number, Staff, TRUE, NULL);
 for(INT i=0; i < Staff_Number; i++)
 {
     CloseHandle(hd[i]);
 }
 system("pause");
 return 0;
}

jeśli użyjesz _beginthread zamiast _beginthreadex, spowoduje to błąd zbyt wielu argumentów dla _beginthread, ponieważ _beginthread nie mógł utworzyć wątku z atrybutem bezpieczeństwa, a także myślę, że _beginthread jest niepotrzebny, możesz bezwzględnie użyć * (_ beginthreadex) i CreateThread

Nie ma już różnicy między nimi.

Wszystkie komentarze dotyczące wycieków pamięci itp. Dotyczą bardzo starych wersji <VS2005. Wiele lat temu przeprowadziłem testy warunków skrajnych i mogę obalić ten mit. Nawet Microsoft miesza style w swoich przykładach, prawie nigdy nie używając _beginthread.