Нарізка Windows: _beginthread vs _beginthreadex vs CreateThread C ++

Що є кращим способом запустити нитку _beginthread, _beginthreadxабо CreateThread?

Я намагаюся визначити , які переваги / недоліки _beginthread, _beginthreadexі CreateThread. Усі ці функції повертають ручку потоку до новоствореного потоку, я вже знаю, що CreateThread надає трохи додаткової інформації, коли виникає помилка (це можна перевірити, зателефонувавши GetLastError) ... але які речі я повинен врахувати, коли я ' м, використовуючи ці функції?

Я працюю з додатком Windows, тому сумісність між платформами вже не йдеться.

Я пройшов документацію msdn і просто не можу зрозуміти, наприклад, чому хтось вирішить використовувати _beginthread замість CreateThread або навпаки.

Ура!

Оновлення: ОК, дякую за всю інформацію, я також читав у кількох місцях, що не можу зателефонувати, WaitForSingleObject()якщо використовував _beginthread(), але якщо я дзвоню _endthread()в потоці, чи не так це? Яка угода там?

CreateThread() - це необмежений виклик API Win32 для створення ще одного потоку управління на рівні ядра.

_beginthread()& _beginthreadex()є дзвінками бібліотеки програми C, які дзвонять CreateThread()за кадром. Після того, як CreateThread()повернувся, _beginthread/ex()піклується про додаткову бухгалтерії , щоб зробити C бібліотека часу виконання корисної і послідовні в новому потоці.

У C ++ ви майже напевно використовуєте, _beginthreadex()якщо ви взагалі не будете посилатися на бібліотеку виконання C (він же MSVCRT * .dll / .lib).

Існує кілька відмінностей між _beginthread()та _beginthreadex(). _beginthreadex()змушений діяти більше як CreateThread()(в обох параметрах і як він веде себе).

Як зазначає Дрю Холл , якщо ви використовуєте час виконання C / C ++, ви повинні використовувати _beginthread()/ _beginthreadex()замість того, CreateThread()щоб час виконання мав шанс виконати власну ініціалізацію потоку (налаштування локального сховища потоків тощо).

На практиці це означає, що CreateThread()майже ніколи не повинен використовуватися безпосередньо вашим кодом.

Документи MSDN для _beginthread()/ _beginthreadex()мають досить детальну інформацію про відмінності - одна з важливіших полягає в тому, що оскільки ручка потоку для потоку, створеного шляхом, _beginthread()автоматично закривається CRT при виході потоку, "якщо потік, створений _beginthread, виходить швидко, ручка, повернута до виклику _beginthread, може бути недійсною або, що ще гірше, вказує на інший потік ".

Ось що _beginthreadex()слід сказати у коментарях до джерела 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).

Оновлення січня 2013 року:

CRT для VS 2012 має додатковий біт ініціалізації, який виконується в _beginthreadex(): якщо процес - це "пакується додаток" (якщо з нього повертається щось корисне GetCurrentPackageId()), час виконання буде ініціалізувати MTA на щойно створеному потоці.

Загалом, правильне робити - це зателефонувати _beginthread()/_endthread()(або ex()варіанти). Однак якщо ви використовуєте CRT як .dll, стан CRT буде належним чином ініціалізований та знищений, оскільки CRT DllMainбуде викликано відповідно DLL_THREAD_ATTACHі DLL_THREAD_DETACHпід час виклику CreateThread()та ExitThread()повернення відповідно.

DllMainКод CRT можна знайти в каталозі установки для VS під VC \ кінескопні \ SRC \ crtlib.c.

Це код в основі _beginthreadex(див. 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;
    }

Решта _beginthreadexініціалізує структуру даних по потоку для CRT.

Перевага використання _beginthread*полягає в тому, що ваші CRT-дзвінки з потоку працюватимуть правильно.

Вам слід використовувати _beginthreadабо _beginthreadexдозволити бібліотеці виконання C робити власну ініціалізацію потоку. Тільки C / C ++ програмісти повинні знати це, як і тепер, правила використання власного середовища розробки.

Якщо ви користуєтесь, _beginthreadвам не потрібно дзвонити, CloseHandleяк це робитиме RTL. Ось чому ви не можете чекати на ручці, якщо ви користувались _beginthread. Також _beginthreadпризводить до плутанини, якщо функція потоку вимикається негайно (швидко), оскільки запускаючий потік, що залишився, тримає недійсну ручку нитки до потоку, який він тільки що запустив.

_beginthreadexручки можна використовувати для очікування, але також вимагати явного дзвінка CloseHandle. Це є частиною того, що робить їх безпечними для використання під час очікування. Існує інша проблема, щоб зробити його абсолютно безпроблемним - це завжди запускати нитку підвішеною. Перевірте успіх, записуйте обробку тощо. Це потрібно для запобігання завершення потоку до того, як запускова нитка зможе записати свою ручку.

Найкраща практика полягає у використанні _beginthreadex, запуску призупинено, а потім відновлення після обробки запису, зачекання на обробці в порядку, CloseHandleпотрібно викликати.

CreateThread()використовується для витоку пам'яті, коли ви використовуєте будь-які функції CRT у своєму коді. _beginthreadex()має ті ж параметри, що CreateThread()і він більш універсальний, ніж _beginthread(). Тому я рекомендую вам скористатися _beginthreadex().

Щодо вашого оновленого запитання: "Я також читав у кількох місцях, що не можу зателефонувати, WaitForSingleObject()якщо використовував _beginthread(), але якщо я дзвоню _endthread()в потоці, чи не так?"

Загалом, ви можете передати ручку потоку до WaitForSingleObject()(або інших API, які чекають на об’єктних ручках), щоб заблокувати, поки нитка не завершиться. Але створена командою потоку _beginthread()закривається, коли _endthread()викликається (що може бути зроблено явно або зроблено неявно до часу виконання, коли процедура потоку повертається).

Проблема викликана в документації для WaitForSingleObject():

Якщо ця ручка закрита, поки очікування все ще триває, поведінка функції не визначено.

Дивлячись на підписи функції, CreateThreadмайже ідентичний _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 
);

У зауваженнях, наведених тут , _beginthreadможе використовуватися __cdeclабо __clrcallвихідна умова як вихідна точка, а також _beginthreadexможе бути використана __stdcallабо __clrcallпочаткова точка.

Я думаю, що будь-які зауваження людей, висловлених щодо витоків пам’яті, CreateThreadвже більше десяти років, і, ймовірно, їх слід ігнорувати.

Цікаво, що обидві _beginthread*функції насправді дзвонять CreateThreadпід капотом C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\crt\srcна моїй машині.

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

beginthreadexдає вам нитку HANDLEдля використання у WaitForSingleObjectта друзях. beginthreadне робить. Не забувайте, CloseHandle()коли закінчите. Справжньою відповіддю було б скористатися boost::threadабо скоро використовувати клас потоку C ++ 09.

У порівнянні _beginthreadз _beginthreadexвами ви можете:

1. Вкажіть атрибути безпеки.
2. Запустіть нитку в підвішеному стані.
3. Ви можете отримати ідентифікатор потоку, з яким можна використовувати OpenThread.
4. Повернута ручка потоку гарантовано буде дійсною, якщо виклик був успішним. Там вам потрібно закрити ручку CloseHandle.
5. Повернута ручка потоку може використовуватися з API синхронізації.

Це _beginthreadexдуже нагадує CreateThread, але перший - це реалізація CRT, а другий - виклик API API. Документація для CreateThread містить таку рекомендацію:

Потік у виконуваному файлі, який викликає бібліотеку часу роботи C (CRT), повинен використовувати функції _beginthreadexта _endthreadexфункції для управління потоками, а не CreateThreadта ExitThread; це вимагає використання багатопотокової версії CRT. Якщо потік, створений за допомогою CreateThreadвикликів CRT, CRT може припинити процес в умовах низької пам'яті.

CreateThread()колись був ні-ні, оскільки ЕПТ буде неправильно ініціалізований / очищений. Але це тепер історія: тепер можна (за допомогою VS2010 та, мабуть, декількох версій назад) зателефонувати, CreateThread()не порушуючи CRT.

Ось офіційне підтвердження MS . У ньому зазначено один виняток:

Насправді, єдина функція, яку не слід використовувати в потоці, створеному за допомогою, CreateThread()- це signal()функція.

Однак, з точки зору послідовності, я особисто вважаю за краще продовжувати використовувати _beginthreadex().

CreateThread()- це виклик Windows API, який не відповідає мові. Він просто створює об’єкт ОС - нитку і повертає HANDLE до цього потоку. Усі програми Windows використовують цей виклик для створення потоків. Усі мови уникають прямого виклику API з очевидних причин: 1. Ви не хочете, щоб ваш код був специфічним для ОС 2. Вам потрібно зробити деякий режим зберігання, перш ніж викликати подібний API: конвертувати параметри та результати, виділити тимчасове зберігання тощо.

_beginthreadex()- це обгортка C, CreateThread()яка відповідає специфіці C. Це дозволяє оригінальним однопоточним C f-ns працювати в багатопотоковому середовищі, виділяючи специфічне для потоку сховище.

Якщо ви не використовуєте CRT, ви не можете уникнути прямого дзвінка на CreateThread(). Якщо ви використовуєте CRT, ви повинні використовувати _beginthreadex()або деякі CRT-рядки f-ns можуть не працювати належним чином до VC2005.

CreateThread()- прямий системний виклик. Він реалізований, з Kernel32.dllяким, швидше за все, ваша програма вже буде пов'язана з інших причин. Він завжди доступний у сучасних системах Windows.

_beginthread()і _beginthreadex()є функцією обгортки в Microsoft C Runtime ( msvcrt.dll). Відмінність між двома дзвінками вказана в документації. Таким чином, він доступний, коли програма Microsoft C Runtime доступна або якщо ваша програма статично пов'язана з нею. Ви, ймовірно, також будете зв'язуватися з цією бібліотекою, якщо ви не кодуєте чистий API Windows (як я часто це роблю).

Ваше запитання є узгодженим і фактично повторюваним. Як і багато API, в API Windows є дублюючі та неоднозначні функціональні можливості. Найгірше, що документація не з'ясовує питання. Я припускаю, що _beginthread()сімейство функцій було створено для кращої інтеграції з іншими стандартними функціоналами C, такими як маніпулювання errno. _beginthread()таким чином, краще інтегрується із часом виконання C.

Незважаючи на це, якщо у вас немає поважних причин для використання _beginthread()або _beginthreadex(), слід використовувати CreateThread(), здебільшого тому, що ви можете отримати одну меншу залежність від бібліотеки в остаточному виконуваному файлі (а для MS CRT це не має значення). Ви також не маєте коду обгортання навколо дзвінка, хоча цей ефект незначний. Іншими словами, я вважаю, що основною причиною дотримання цього CreateThread()є те, що для початку немає жодної вагомої причини _beginthreadex(). Функціональні можливості точно або майже однакові.

Хорошим приводом для використання _beginthread() було б (як це здається помилковим), щоб об'єкти C ++ були правильно розмотані / знищені, якщо _endthread()викликали.

В інших відповідях не вдалося обговорити наслідки виклику функції часу виконання C, яка охоплює функцію API Win32. Це важливо, враховуючи поведінку блокування навантажувача DLL.

Незалежно від того, чи _beginthread{ex}існує якесь спеціальне управління потоком / волоконною пам’яттю C Runtime, як обговорюються інші відповіді, воно реалізується в (припускаючи динамічне посилання на час виконання C) DLL, які процеси, можливо, ще не завантажені.

Дзвонити не безпечно _beginthread* звідсиDllMain . Я перевірив це, написавши DLL, завантажений за допомогою функції Windows "AppInit_DLLs". Виклик _beginthreadex (...)замість цього CreateThread (...)призводить до того, що багато важливих частин Windows припиняє роботу під час завантаження, оскільки DllMainтупикові точки входу, які очікують звільнення блокування завантажувача для виконання певних завдань ініціалізації.

До речі, саме тому kernel32.dll має багато рядкових функцій, що перекриваються, що також виконує C-час - використовуйте ті, DllMainщоб уникнути подібних ситуацій.

Якщо ви читаєте книгу Налагодження програми Windows від Джеффрі Ріхтера в ній, він пояснює, що майже у всіх випадках вам потрібно зателефонувати, _beginthreadexа не телефонувати CreateThread. _beginthreadце просто спрощена обгортка навколо_beginthreadex .

_beginthreadex ініціалізує певні внутрішні протоколи CRT (C RunTime), що CreateThread API не робив би.

Наслідок, якщо ви використовуєте CreateThread API замість використання _begingthreadexдзвінків до функцій CRT, можуть несподівано спричинити проблеми.

Перевірте цей старий журнал Microsoft від Ріхтера.

Ніякої різниці між обома.

Усі коментарі щодо витоків пам'яті тощо базуються на дуже старих версіях <VS2005. Я робив кілька стрес-тестувань років тому і міг розвінчати цей міф. Навіть Microsoft змішує стилі у своїх прикладах, майже ніколи не використовуючи _beginthread.