Различие между процессами и потоками в Linux

17

После прочтения этого ответа и «Развитие ядра Linux» Роберта Лав и, впоследствии, в системном вызове clone() , я обнаружил, что процессы и потоки в Linux (почти) неотличимы от ядра. Есть несколько настроек между ними (обсуждается как «более общий доступ» или «меньше обмена» в запрошенном вопросе SO), но у меня все еще есть некоторые вопросы, на которые еще нужно ответить.

Недавно я работал над программой, включающей пару потоков POSIX, и решил поэкспериментировать с этой предпосылкой. В процессе, который создает два потока, все потоки, конечно, получают уникальное значение, возвращаемое pthread_self() , однако , а не getpid() .

Ниже приведен пример программы, которую я создал:

#include <stdio.h>
#include <stdlib.h>
#include <stdint.h>
#include <unistd.h>
#include <pthread.h>

void* threadMethod(void* arg)
{
    int intArg = (int) *((int*) arg);

    int32_t pid = getpid();
    uint64_t pti = pthread_self();

    printf("[Thread %d] getpid() = %d\n", intArg, pid);
    printf("[Thread %d] pthread_self() = %lu\n", intArg, pti);
}

int main()
{
    pthread_t threads[2];

    int thread1 = 1;

    if ((pthread_create(&threads[0], NULL, threadMethod, (void*) &thread1))
         != 0)
    {
        fprintf(stderr, "pthread_create: error\n");
        exit(EXIT_FAILURE);
    }

    int thread2 = 2;

    if ((pthread_create(&threads[1], NULL, threadMethod, (void*) &thread2))
         != 0)
    {
        fprintf(stderr, "pthread_create: error\n");
        exit(EXIT_FAILURE);
    }

    int32_t pid = getpid();
    uint64_t pti = pthread_self();

    printf("[Process] getpid() = %d\n", pid);
    printf("[Process] pthread_self() = %lu\n", pti);

    if ((pthread_join(threads[0], NULL)) != 0)
    {
        fprintf(stderr, "Could not join thread 1\n");
        exit(EXIT_FAILURE);
    }

    if ((pthread_join(threads[1], NULL)) != 0)
    {
        fprintf(stderr, "Could not join thread 2\n");
        exit(EXIT_FAILURE);
    }

    return 0;
}

(Это было скомпилировано [ gcc -pthread -o thread_test thread_test.c ] в 64-битной Fedora, из-за 64-битных типов, используемых для pthread_t , полученных из <bits/pthreadtypes.h> , для компиляции в 32-разрядных версиях код потребует незначительных изменений. )

Выход, который я получаю, выглядит следующим образом:

[[email protected] ~]$ ./thread_test 
[Process] getpid() = 28549
[Process] pthread_self() = 140050170017568
[Thread 2] getpid() = 28549
[Thread 2] pthread_self() = 140050161620736
[Thread 1] getpid() = 28549
[Thread 1] pthread_self() = 140050170013440
[[email protected] ~]$ 

Используя блокировку планировщика в gdb , я могу сохранить программу и ее потоки живыми, чтобы я мог зафиксировать, что top говорит, что просто показывает процессы :

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
28602 bean      20   0 15272 1112  820 R  0.4  0.0   0:00.63 top
 2036 bean      20   0  108m 1868 1412 S  0.0  0.0   0:00.11 bash
28547 bean      20   0  231m  16m 7676 S  0.0  0.4   0:01.56 gdb
28549 bean      20   0 22688  340  248 t  0.0  0.0   0:00.26 thread_test
28561 bean      20   0  107m 1712 1356 S  0.0  0.0   0:00.07 bash

И при показе потоков, говорит:

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
28617 bean      20   0 15272 1116  820 R 47.2  0.0   0:00.08 top
 2036 bean      20   0  108m 1868 1412 S  0.0  0.0   0:00.11 bash
28547 bean      20   0  231m  16m 7676 S  0.0  0.4   0:01.56 gdb
28549 bean      20   0 22688  340  248 t  0.0  0.0   0:00.26 thread_test
28552 bean      20   0 22688  340  248 t  0.0  0.0   0:00.00 thread_test
28553 bean      20   0 22688  340  248 t  0.0  0.0   0:00.00 thread_test
28561 bean      20   0  107m 1860 1432 S  0.0  0.0   0:00.08 bash

Понятно, что программы, или, возможно, ядро, имеют четкий способ определения потоков в отличие от процессов. Каждый поток имеет свой собственный PID в соответствии с top - почему?

    
задан Doddy 06.02.2012 в 02:22
источник
  • clone () - это то, как Linux реализует как потоки, так и fork (). Все, что имеет значение, заключается в том, что разговор с ПИД-передающим сигналом передается всем, кто должен знать. Если ядро ​​присваивает потокам дополнительные идентификаторы, это не ваш бизнес, и это не влияет на то, как вы разговариваете с вашими процессами. –  Kerrek SB 06.02.2012 в 02:33
  • Хорошая ссылка для прохождения. –  Aniket Thakur 16.03.2014 в 11:42
  • «процессы и потоки в Linux почти неразличимы для ядра». Умм, не совсем так. Вы почти ничего не можете сказать о том, как работает ядро ​​Linux, что верно как для процессов, так и для потоков. Имеет вид vm? Только процессы. Может быть запланировано? Только потоки. Имеет таблицу дескриптора файла? Только процессы. Имеет приоритет? Только потоки. И так далее по линии. –  David Schwartz 09.03.2017 в 07:02

3 ответа

29

Все эти путаницы связаны с тем, что разработчики ядра изначально считали иррациональное и неправильное представление о том, что потоки могут быть реализованы почти полностью в пользовательском пространстве с использованием процессов ядра в качестве примитива, при условии, что ядро ​​предложило способ совместного использования памяти и файловые дескрипторы. Это привело к заведомо плохой реализации LinuxThreads потоков POSIX, что было довольно неправильным, потому что это не дало ничего отдаленно напоминающего семантику потоков POSIX. В итоге LinuxThreads был заменен (NPTL), но многие запутанные термины и недоразумения сохраняются.

Первым и самым важным для понимания является то, что «PID» означает разные вещи в пространстве ядра и пространстве пользователя. То, что ядро ​​вызывает PID, на самом деле - это идентификаторы потоков на уровне ядра (часто называемые TID), а не путать с pthread_t , который является отдельным идентификатором. Каждый поток в системе, будь то в том же процессе или другой, имеет уникальный TID (или «PID» в терминологии ядра).

Считается, что PID в POSIX-смысле «процесс», с другой стороны, называется «идентификатором группы потоков» или «TGID» в ядре. Каждый процесс состоит из одного или нескольких потоков (процессов ядра), каждый из которых имеет свой собственный идентификатор TID (kernel PID), но все используют один и тот же TGID, который равен TID (ядро PID) исходного потока, в котором выполняется main .

Когда top показывает вам потоки, он показывает TID (ядро PID), а не PID (ядро TGID), и именно поэтому каждый поток имеет отдельный файл.

С появлением NPTL большинство системных вызовов, которые принимают аргумент PID или действуют на вызывающий процесс , были изменены, чтобы рассматривать PID как TGID и действовать во всей «группе потоков» (POSIX процесс).     

ответ дан R.. 06.02.2012 в 02:33
  • Спасибо за ваш ответ, и я буду изучать то, что вы говорите, без сомнения. Возможно, самый большой вопрос из моего поста сегодня (насколько я могу судить): «Почему другие не спрашивали об этом?» (По крайней мере, через легкодоступный ресурс.) Конечно, это должна быть большая тема для тех, кто, как и я, участвует в многопоточных приложениях? –  Doddy 06.02.2012 в 03:15
  • В настоящее время (теперь, когда мы прошли фиаско LinuxThreads), программисты приложений действительно могут просто заниматься бизнесом с использованием потоков POSIX, как указано POSIX, не беспокоясь о том, что происходит под капотом, потому что все работает в основном правильно. Я подозреваю, что именно поэтому детали реализации больше не получают большого внимания. BTW man 7 pthreads имеет некоторое базовое объяснение того, как это работает. –  R.. 06.02.2012 в 04:43
  • @bean - вопрос был задан многими разными способами с разных точек зрения. R дал особенно хороший ответ, поскольку он затрагивает несколько уровней путаницы как с исторической, так и с технической точки зрения. –  Duck 06.02.2012 в 04:44
  • Очень полезно, спасибо –  Jonathan Henson 22.02.2012 в 00:17
1

Представьте себе какую-то «мета-сущность». Если компания не имеет ни одного из ресурсов (адресное пространство, файловые дескрипторы и т. Д.) Своего родителя, то это процесс, и если объект разделяет все ресурсы своего родителя, то это поток. У вас даже может быть что-то наполовину между процессом и потоком (например, некоторые ресурсы разделены, а некоторые не разделены). Взгляните на системный вызов «clone ()» (например, Ссылка ), и вы увидите, что это так Linux делает все внутри.

Теперь скрыть это за какой-то абстракцией, которая делает все похожим на процесс или поток. Если абстракция безупречна, вы никогда не узнаете разницу между «сущностями» и «процессами и потоками». Абстракция не совсем безупречна - PID, который вы видите, на самом деле является «идентификатором объекта».

    
ответ дан Brendan 06.02.2012 в 02:38
  • Извините, ваш ответ вообще не проливает свет на мой вопрос. Я уже посмотрел man-страницу clone (). То, что была абстракция между процессами и потоками, заставило меня задать вопрос в первую очередь. Очень легко сказать, что, поскольку я выбрал callon () с общим ресурсом менее 50%, мне должен быть предоставлен поток, а не процесс, а также. –  Doddy 06.02.2012 в 03:22
0

В Linux каждый поток получает идентификатор потока . Идентификатор потока основного потока выполняет двойную функцию как идентификатор процесса (и довольно хорошо известен в пользовательском интерфейсе). Идентификатор потока является деталью реализации Linux и не связан с идентификатором POSIX. Для получения дополнительной информации см. Системный вызов gettid (недоступен с чистого Python, поскольку он зависит от конкретной системы).     

ответ дан phihag 06.02.2012 в 02:32
  • Я не уверен, что Идентификатор потока основного потока выполняет двойной долг, поскольку идентификатор процесса является истинным. Когда я запускал код выше, идентификатор потока основного потока был не таким же, как PID. –  codeforester 09.03.2017 в 07:23