Различие между процессами и потоками в Linux
После прочтения этого ответа и "Развитие ядра 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
- почему?
Ответы
Ответ 1
Все эти путаницы связаны с тем, что разработчики ядра изначально считали иррациональное и неправильное представление о том, что потоки могут быть реализованы почти полностью в пользовательском пространстве с использованием процессов ядра в качестве примитива, при условии, что ядро предложило способ совместного использования памяти и файловые дескрипторы. Это привело к заведомо плохой реализации LinuxThreads потоков POSIX, что было довольно неправильным, потому что это не дало ничего отдаленно напоминающего семантику потоков POSIX. В итоге LinuxThreads был заменен (NPTL), но многие запутанные термины и недоразумения сохраняются.
Первым и самым важным для понимания является то, что "PID" означает разные вещи в пространстве ядра и пространстве пользователя. То, что ядро вызывает PID, на самом деле - это идентификаторы потоков на уровне ядра (часто называемые TID), а не путать с pthread_t
, который является отдельным идентификатором. Каждый поток в системе, будь то в одном и том же процессе или другой, имеет уникальный TID (или "PID" в терминологии ядра).
То, что считало PID в смысле POSIX "процесса", с другой стороны, называется "идентификатором группы потоков" или "TGID" в ядре. Каждый процесс состоит из одного или нескольких потоков (процессов ядра), каждый из которых имеет свой собственный TID (ядро PID), но все используют один и тот же TGID, который равен TID (ядро PID) исходного потока, в котором выполняется main
.
Когда top
показывает ваши потоки, он показывает TID (ядро PID), а не PID (ядро TGID), и именно поэтому каждый поток имеет отдельный файл.
С появлением NPTL большинство системных вызовов, которые принимают аргумент PID или действуют на вызывающий процесс, были изменены для обработки PID как TGID и действуют на всю "группу потоков" (процесс POSIX).
Ответ 2
Представьте себе какую-то "мета-сущность". Если компания не имеет ни одного из ресурсов (адресного пространства, файловых дескрипторов и т.д.) Своего родителя, то это процесс, и если объект разделяет все ресурсы своего родителя, то это поток. У вас даже может быть что-то наполовину между процессом и потоком (например, некоторые ресурсы разделены, а некоторые не разделены). Взгляните на системный вызов "clone()" (например, http://linux.die.net/man/2/clone), и вы увидите, что Linux делает вещи внутренне.
Теперь скрыть это за какой-то абстракцией, которая делает все похожим на процесс или поток. Если абстракция безупречна, вы никогда не узнаете разницу между "сущностями" и "процессами и потоками". Абстракция не совсем безупречна - PID, который вы видите, на самом деле является "идентификатором объекта".
Ответ 3
В Linux каждый поток получает идентификатор потока . Идентификатор потока основного потока выполняет двойную функцию как идентификатор процесса (и довольно хорошо известен в пользовательском интерфейсе). Идентификатор потока является деталью реализации Linux и не связан с идентификатором POSIX. Для получения дополнительной информации см. Системный вызов gettid (недоступен с чистого Python с его системной спецификой).