Python-сообщество

Здравствуйте, интересует возможность и особенности организации многопоточных алгоритмов на Python. Уперся в однопоточность и псевдо-многопоточность PHP, искал альтернативы, нашел Python.

Если не трудно, мне было бы крайне интересно услышать ликбез по этому вопросу от опытной аудитории:

1) Эффективна ли реализация множества потоков с точки зрения потребления памяти
2) Какие особенности работы с потоками (управление)
3) Как на низком уровне реализуются потоки? (в частности, механизм распределения памяти)


P.S. Прошу прощения за вероятную глупость в своем вопросе, но мне хотелось бы уяснить для себя механизмы использования нитей (threads) и дочерних процессов (fork).

C точки зрения быстродействия и вообще целесообразности, в чем преимущество использования нитей? Отсутствие накладных расходов на уровне ОС для fork() основного процесса?


—

С уважением,
XCoder.

Отредактировано (Окт. 23, 2011 23:36:22)

Немного пошарился по теме и нашел вот это:

>>> У Python нет средств для определения, какой поток должен запуститься следующим. Нет приоритетов, вытесняющей многозадачности, round-robin и т.п. Эта функция целиком возлагается на операционную систему. Это одна из причин странной работы сигналов: интерпретатор никак не может контроллировать запуск потоков, он просто переключает их как можно чаще, надеясь, что запустится главный поток.



WTF ? o_O

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

Хм… интересно. Меня немного смутил нюанс с блокировкой из статьи, ссылку на которую я приводил. В ней утверждается, что треды псевдопараллельны, иными словами они в любом случае в рамках одного ядра цпу будут выполняться последовательно, прерываясь в моменты I/O операций, требуемых выполняемому потоку.

Если в целом, то я хотел бы разобраться, это нюанс исключительно реализации интерпретатора питона?

Еще вопрос к опытной аудитории, в таком случае, каким образом наиболее эффективно использовать асинхронные многопоточные алгоритмы?

Моя задача, имея N-процессорных ядер задействовать их все, распределив по ним вычислительную нагрузку.


P.S. Ушел изучать аспекты ядра UNIX…

Отредактировано (Окт. 24, 2011 22:59:25)

XCoder
Моя задача, имея N-процессорных ядер задействовать их все, распределив по ним вычислительную нагрузку.

Для вычислительной нагрузки нужны процессы.

Я использую потоки в двух случаях:
1. для запросов по сети (когда нужно параллельно скачать несколько страниц)
2. чтобы не тормозило GUI (долгую операцию выполняем в потоке)

Люди! Процессы - те же нитки (потоки, как вы их еще называете), только процессы - это уровень операционной системы, а нитки - это уровень программы (процесса). Конечно, и те и другие находятся под контролем операционной системы. Нитки, если их несколько и если они друг друга не лочат (например, при синхронизации, которую вы сами делаете), выполняются на разных ядрах (или процессорах), если таковые есть в наличии (как правило, есть). Что касается GUI, то тут нитки противопоказаны. Две нитки не могут одновременно рисовать, например, линии. Это особенность как драйверов, как карты, так и самой ОС (в частности, винды).

Isem
Процессы - те же нитки (потоки, как вы их еще называете), только процессы - это уровень операционной системы, а нитки - это уровень программы (процесса). Конечно, и те и другие находятся под контролем операционной системы. Нитки, если их несколько и если они друг друга не лочат (например, при синхронизации, которую вы сами делаете), выполняются на разных ядрах (или процессорах), если таковые есть в наличии (как правило, есть).

Это всё не про Python. Потоки в нём не “выполняются на разных ядрах (или процессорах)”.

Потоки стандартного модуля threading выполняются одним процессором, но разделяют данные.
Процессы стандартного модуля multiprocessing погут выполняться на разных процессорах и не имеют общих данных. Хотя можно имитировать общие данные с помощью менеджеров (см. multiprocessing.Manager() и т.п.).

Isem
Что касается GUI, то тут нитки противопоказаны. Две нитки не могут одновременно рисовать, например, линии. Это особенность как драйверов, как карты, так и самой ОС (в частности, винды).

Не противопоказаны, но надо понимать где применять. Нажал на кнопку “Обработать данные” - запустился поток обработки данных, и при этом всё приложение не зависает и пользователь может использовать другие элементы GUI.

1 Мне кажется надо договориться - говорим об обычном CPython
2 Питон пускает несколько тредов (в чем можно легко убедиться просканировав треды текущего процесса).
3

Isem
они друг друга не лочат (например, при синхронизации, которую вы сами делаете)

Кроме своих залочиваний есть GIL из-за которого потоки могут много проистаивать.

Kogrom
4 Потоки стандартного модуля threading выполняются одним процессором

насколько я знаю - это не верно см пункт 2.
5 Есть вопрос который интересно прояснить: По моим наблюдениям - GIL освобождается перед вызовом компилированного кода (в том числе и IO). Поэтому если пустить из тредов долгоидграющие прочедуры то они не будут мешать друг другу. Это так?

Отредактировано (Окт. 25, 2011 20:46:21)

doza_and
1 Мне кажется надо договориться - говорим об обычном CPython

Да. Кстати, у Вас там не везде верное цитирование.

doza_and

Kogrom
4 Потоки стандартного модуля threading выполняются одним процессором

насколько я знаю - это не верно см пункт 2.
5 Есть вопрос который интересно прояснить: По моим наблюдениям - GIL освобождается перед вызовом компилированного кода (в том числе и IO). Поэтому если пустить из тредов долгоидграющие прочедуры то они не будут мешать друг другу. Это так?

Возможно, я немного погорячился, но вот что пишут в документации про GIL (http://docs.python.org/glossary.html#term-global-interpreter-lock):

The lock used by Python threads to assure that only one thread executes in the CPython virtual machine at a time. This simplifies the CPython implementation by assuring that no two processes can access the same memory at the same time. Locking the entire interpreter makes it easier for the interpreter to be multi-threaded, at the expense of much of the parallelism afforded by multi-processor machines. Efforts have been made in the past to create a “free-threaded” interpreter (one which locks shared data at a much finer granularity), but so far none have been successful because performance suffered in the common single-processor case.

То есть один поток в одно время. И разницы от того, что у вас несколько процессоров быть не должно.

Про неверное цитирование верно большое спасибо - ща исправлю. Со мной чтото второй раз уже так - если в одной сессии нескольких людей цитирую.

Помоему простое описание такое - GIL освобождается при любых вызовах внешних процедур (не только IO). Если кусок кода критический, то он откомпилирован => будет нормально паралеллиться threading. Поэтому лично для меня они не накладывают серьезных ограничений.