Потоки Windows: _beginthread против _beginthreadex против CreateThread C ++

Какой лучший способ начать обсуждение _beginthread, _beginthreadxили CreateThread?

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

Я работаю с приложением Windows, поэтому о кроссплатформенной совместимости уже не может быть и речи.

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

Ура!

Обновление: хорошо, спасибо за всю информацию, я также прочитал в нескольких местах, которые я не могу назвать, WaitForSingleObject()если бы использовал _beginthread(), но если я позвоню _endthread()в поток, не должно ли это работать? В чем дело?

CreateThread() - это необработанный вызов Win32 API для создания еще одного потока управления на уровне ядра.

_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 противCreateThread

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, а второй - вызовом Windows API. В документации по CreateThread есть следующие рекомендации:

Поток в исполняемом файле , который вызывает C библиотеку времени выполнения (CRT) следует использовать _beginthreadexи _endthreadexфункцию для управления потоками , а не CreateThreadи ExitThread; это требует использования многопоточной версии CRT. Если поток, созданный с использованием, CreateThreadвызывает CRT, CRT может завершить процесс в условиях нехватки памяти.

CreateThread()когда-то было нет-нет, потому что CRT неправильно инициализировал / очищал. Но это уже история: теперь можно (используя 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()иначе некоторые строки f-n CRT могут не работать должным образом до VC2005.

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

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

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

Несмотря на это, если у вас нет веских причин для использования _beginthread()или _beginthreadex(), вам следует использовать CreateThread(), в основном потому, что вы можете получить на одну библиотечную зависимость меньше в вашем конечном исполняемом файле (а для MS CRT это имеет немного значение). У вас также нет кода оболочки вокруг вызова, хотя этот эффект незначителен. Другими словами, я считаю, что основная причина, по которой CreateThread()стоит придерживаться этого правила, заключается в том, что _beginthreadex()для начала нет веской причины . Функциональные возможности в точности или почти одинаковы.

Одной из веских причин для использования _beginthread() было бы (что кажется ложным), что объекты C ++ будут должным образом развернуты / уничтожены, если они _endthread()были вызваны.

В других ответах не обсуждаются последствия вызова функции времени выполнения C, которая обертывает функцию Win32 API. Это важно при рассмотрении поведения блокировки загрузчика DLL.

Независимо от того, _beginthread{ex}выполняет ли какое-либо специальное управление памятью потоков / волокон во время выполнения C, как обсуждают другие ответы, оно реализовано (при условии динамического связывания со средой выполнения 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), которые CreateThreadAPI не выполняет.

Последствие использования CreateThreadAPI вместо использования _begingthreadexвызовов функций CRT может привести к неожиданным проблемам.

Ознакомьтесь с этим старым журналом Microsoft Journal от Рихтера.

Между ними больше нет разницы.

Все комментарии об утечках памяти и т. Д. Основаны на очень старых версиях <VS2005. Я провел несколько стресс-тестов много лет назад и смог развенчать этот миф. Даже Microsoft смешивает стили в своих примерах, почти никогда не используя _beginthread.