LINUX.ORG.RU

треды в линукс

 ,


0

3

Есть прога на C которая использует <pthread.h> Когда её запускаешь ps -a показывает только один процесс, а htop показывает кучу процессов (соответствует количеству тредов) у каждого есть pid и тд, и соответственно загружают они все ядра процессора.

Вопрос: Почему ps показывает только один процесс а не все как htop? С каких пор треды создают новые процессы? (да с разморозкой меня)

★★★★★

Продемонстрируй скриншотами, что ты имеешь в виду.

Deleted ()

Почему ps показывает только один процесс а не все как htop?

Исторически, наверное. Он умеет показывать и нити тоже.

С каких пор треды создают новые процессы?

_Не_ создают. Со времен NPTL (лет 12-15).

tailgunner ★★★★★ ()

Потоки в линуксе с точки зрения ядра это процессы, которые используют общее адресное пространство (и некоторые другие объекты ядра). Разные утилиты по-разному обрабатывают потоки, некоторые оставляют только один, а некоторые все по умолчанию (там есть ссылка на главный поток и он сам ссылается на себя, а остальные на него; так можно отфильтровать второстепенные потоки). С нужными флагами обычно можно добится обоих типов отображения.

xaizek ★★★★★ ()

Потому, что htop у тебя настроен (f2/htoprc) так, что бы показывать потоки.

А в ps надо ключек передать (-T).

pon4ik ★★★★★ ()
Ответ на: комментарий от xaizek

Получается они не только с точки зрения ядра разные процессы, а в принципе разные процессы с общим адресным пространством. Их например килять можно по любому из pid-ов.

TDrive ★★★★★ ()

в общем понял всем спс.

TDrive ★★★★★ ()
Ответ на: комментарий от kirk_johnson

Создают

См. https://www.akkadia.org/drepper/nptl-design.pdf, «Kernel Improvements». Если ты этого утверждаешь, что «ядро создает процессы, как и раньше» - окей.

Это совершенно отдельный task_struct

Малозначащая деталь реализации.

с совершенно отдельным PID

А getpid разных тредов выдает одно и то же число.

tailgunner ★★★★★ ()
Ответ на: комментарий от tailgunner

Малозначащая деталь реализации.

Эта «малозначащая деталь» позволяет прибивать треды к процессорам и делать прочие штуки, которые можно делать с обычными процессами.

А getpid разных тредов выдает одно и то же число.

Ага. И чо?

kirk_johnson ★☆ ()
Ответ на: комментарий от tailgunner

А getpid разных тредов выдает одно и то же число.

Так это просто абстракция от конкретной реализации. В другой какой нибудь системе треды могут быть реализованы без создания процессов.

TDrive ★★★★★ ()
Ответ на: комментарий от tailgunner

И чо?

То, что треды реализованы через процессы, позволяет без дополнительных костылей использовать существующие методы управления процессами.

И всё.

Нет, конечно.

kirk_johnson ★☆ ()
Ответ на: комментарий от TDrive

А getpid разных тредов выдает одно и то же число.

Так это просто абстракция от конкретной реализации

Ы? Это требование стандарта.

В другой какой нибудь системе треды могут быть реализованы без создания процессов.

Конечно.

tailgunner ★★★★★ ()
Ответ на: комментарий от tailgunner

Ы? Это требование стандарта.

требования стандарта это и есть абстракция, а мы про конкретную реализацию.

TDrive ★★★★★ ()
Последнее исправление: TDrive (всего исправлений: 1)
Ответ на: комментарий от ZenitharChampion

Вон там по ссылке написано

The PID space has been extended to a maximum of 2 billion threads on IA-32

Так что не парься.

TDrive ★★★★★ ()
Ответ на: комментарий от tailgunner

Через процессы они были реализованы раньше. А сейчас... см. вопрос выше.

Они и сейчас реализованы через процессы. Просто ты по какой-то странной причине отказываешься это признать.

Вот тебе даже кусок man 2 clone:

       CLONE_THREAD (since Linux 2.4.0-test8)
              If CLONE_THREAD is set, the child is placed in the  same  thread
              group as the calling process.  To make the remainder of the dis‐
              cussion of CLONE_THREAD more readable, the term "thread" is used
              to refer to the processes within a thread group.

              Thread  groups  were a feature added in Linux 2.4 to support the
              POSIX threads notion of a set of threads  that  share  a  single
              PID.   Internally, this shared PID is the so-called thread group
              identifier (TGID) for the thread group.  Since Linux 2.4,  calls
              to getpid(2) return the TGID of the caller.

kirk_johnson ★☆ ()
Последнее исправление: kirk_johnson (всего исправлений: 1)
Ответ на: комментарий от tailgunner

Ман слоне. Линуксу пофих что поцесс, что поток, одна хрень

anonymous ()
Ответ на: комментарий от ZenitharChampion

Важно не сколько их, а в каком они состоянии. В спячке они тратят только память.

pon4ik ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.