Вопрос по multithreading, posix, linux – Параллельность потоков posix в многопроцессорной машине

5

У меня есть некоторые сомнения относительно параллельности потоков posix в многопроцессорной машине. Я нашел похожие вопросы в SO относительно этого, но не нашел окончательного ответа.

Ниже мое понимание. Я хочу знать, прав ли я.

Posix threads are user level threads and kernel is not aware of it.

Kernel scheduler will treat Process( with all its threads) as one entity for scheduling. It is the thread library that in turn chooses which thread to run. It can slice the cpu time given by the kernel among the run-able threads.

User threads can run on different cpu cores. ie Let threads T1 & T2 be created by a Process(T), then T1 can run in Cpu1 and T2 can run in Cpu2 BUT they cant run concurrently.

Пожалуйста, дайте мне знать, если мое понимание правильно.

Спасибо...

Все ваши баллы неверны, так как я уверен, что на других постерах написано & lt; g & gt; Martin James

Ваш Ответ

3   ответа
9

Поскольку вы отметили свой вопрос как "Linux" Я собираюсь ответить на него в соответствии со стандартной реализацией pthreads в Linux. Если вы говорите о& Quot; зеленый & Quot; потоки, которые запланированы на уровне VM / language вместо ОС, тогда ваши ответы в основном правильные. Но мои комментарии ниже о Linux pthreads.

1) Posix threads are user level threads and kernel is not aware of it.

Нет, это, конечно, не правильно. Ядро Linux и библиотеки pthreads работают вместе для администрирования потоков. Ядро выполняет переключение контекста, планирование, управление памятью, управление кеш-памятью и т. Д. Конечно, на уровне пользователя выполняется другое администрирование, но без ядра большая часть мощности pthreads будет потеряна.

2) Kernel scheduler will treat Process( with all its threads) as one entity for scheduling. It is the thread library that in turn chooses which thread to run. It can slice the cpu time given by the kernel among the run-able threads.

Нет, ядро обрабатывает каждый поток процесса как одну сущность. Он имеет свои собственные правила по срезанию времени, которые учитывают процессы (и приоритеты процессов), но каждый поток подпроцесса является планируемым объектом.

3) User threads can run on different cpu cores. ie Let threads T1 & T2 be created by a Process(T), then T1 can run in Cpu1 and T2 can run in Cpu2 BUT they cant run concurrently.

Нет. Ожидается параллельное выполнение многопоточных программ. Вот почему синхронизация и мьютексы так важны, и почему программисты мириться со сложностью многопоточного программирования.


Один из способов доказать это вам - посмотреть на результатps с-L возможность показать связанные темы.ps обычно оборачивает несколько потоковых процессов в одну строку, но с-L вы можете видеть, что ядро имеет отдельный виртуальный идентификатор процесса для каждого потока:

ps -ef | grep 20587
foo    20587     1  1 Apr09 ?        00:16:39 java -server -Xmx1536m ...

против

ps -eLf | grep 20587
foo    20587     1 20587  0  641 Apr09 ?    00:00:00 java -server -Xmx1536m ...
foo    20587     1 20588  0  641 Apr09 ?    00:00:30 java -server -Xmx1536m ...
foo    20587     1 20589  0  641 Apr09 ?    00:00:03 java -server -Xmx1536m ...
...

Я не уверен, что потоки Linux все еще делают это, но исторически pthreads использовалclone(2) системный вызов, чтобы создать другую копию потока себя:

Unlike fork(2), these calls allow the child process to share parts of its execution context with the calling process, such as the memory space, the table of file descriptors, and the table of signal handlers.

Это отличается отfork(2) который используется при создании другого полного процесса.

Error: User Rate Limit Exceeded hackrock
Error: User Rate Limit Exceeded
0

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

Итак, на большинстве современных ОС:

A process with POSIX threads is no different to the kernel than any other process with multiple threads.

The kernel scheduler dispatches threads, not processes. A 'process' is often regarded as a higher-level construct that has code, memory-management, quotas, auditing, and security permissions, but not execution. A process can do nothing unless a thread runs its code, which is why, when a process is created, a 'main thread' is created at the same time, else nothing would run. The OS scheduling algorithm may use the process that the thread runs as one of the parameters to decide on which set of ready threads to run next - it's cheaper to swap one thread out with one from the same process - but it does not have to.

Slicing the cpu time given by the kernel among the run-able threads is a side-effect of the OS timer interrupt when there are more ready threads than there are cores to run them. Any machine that regularly has to resort to (ugh! - I hate the term), 'time slicing' should be regarded as overloaded and should have more CPU or less work. Threads should ideally only become ready when signaled by another thread or an IO driver, not because the OS timer interrupt has decided to run it in place of another thread that could still be doing useful work.

They just can run concurrently. If two threads are ready and there are two cores, the threads are dispatched onto the two cores. It does not matter if they are from the same process or not.

5

POSIX не определяет, как потоки, созданные сpthread_create запланированы на процессорных ядер. Это до реализации.

Тем не менее, я ожидал бы следующего в качественной реализации, и это относится к текущим версиям Linux:

  • Threads are full kernel threads, and scheduled by the kernel
  • Threads from the same process can run concurrently on separate processors

то есть все 3 ваших пронумерованных оператора неверны с текущими реализациями linux, но теоретически могут быть верны для другой реализации, которая также соответствует POSIX.

Error: User Rate Limit Exceeded hackrock

Похожие вопросы