Comments 16
>> Вследствие блокировки GIL, те без оного все будет ок?
Однако, когда Python начал использоваться для многопоточных приложений, стало очевидным, что возникают проблемы с одновременным доступом к общим ресурсам. Поэтому Гвидо ван Россум и команда разработчиков внедрили GIL, чтобы обеспечить безопасность работы с памятью и объектами Python.
Взаимодействие потоков с GIL может привести к неожиданным результатам, особенно если не учитывать блокировки и многозадачность. Когда несколько потоков пытаются изменить одни и те же данные, могут возникнуть гонки данных (race conditions).
Звучит так, как будто хотели пофиксить проблему, но в итоге не пофиксили, а сделали хуже.
По-моему, надо было сделать два режима работы программы. Один основной, с GIL, а второй без него - при запуске программы она бы делала что-то вроде GIL.disable(), и использовала бы потом мютексы, рвлоки и т.п.
По-моему, надо было сделать два режима работы программы
Вот тут уже делают по-вашему https://github.com/colesbury/nogil :) Кстати, у них классно описаны компромиссы для GIL и non-GIL реализаций в документе Python Multithreading without GIL.
В целом, GIL даёт гарантии, что состояние самого интерпретатора не будет поломано в многопоточной среде. Это на самом деле очень крутая фича, без которой отладка пользовательского кода при невнимательном использовании потоков превратилась бы в ад.
Сейчас в PEP 684 (python 3.12) и PEP 554 (хотят в 3.13, но скорее позже) проблему пытаются фиксить ещё и с другой стороны - избавляясь от излишне глобального и мутабельного состояния интерпретатора везде, где только можно. Но там ещё куча работы.
Сейчас в PEP 684 (python 3.12) и PEP 554 (хотят в 3.13, но скорее позже) проблему пытаются фиксить ещё и с другой стороны - избавляясь от излишне глобального и мутабельного состояния интерпретатора везде, где только можно.
Есть опасения, что это скорее усложнит код самого интерпретатора, но цель останется недостигнута.
На практике есть куча задач, которые прекрасно решаются в один поток как в node.js, без всей этой чехорды.
И есть куча задач, которые хорошо распараллеливаются, и получают огромный буст от запуска на всех ядрах процессора.
Для этого есть масса способов https://www.nersc.gov/assets/Uploads/07-Scaling-Python-Applications.pdf. Например, чтобы распараллеливать вычисления вам не нужна многопоточная программа - вам нужно много однопоточных программ, исполняющихся в разных потоках. Эта модель покрывается sub-interpreters из PEP 684 (проблема лишь в бинарных библиотеках, которые могут пока не быть рассчитаны на такое использование). Многопоточность, когда именно самой программе нужно прерываться это скорее десктопная история ради отзывчивости. Но и здесь можно оставить ui в один поток, а вычисления вынести в воркеры.
Не понял в чём разница плохого варианта от хорошего в 7 совете. Созданием двух циклов?
"Используйте алгоритмы с линейным временем выполнения:
При
выборе алгоритмов старайтесь использовать те, которые имеют линейное
время выполнения (O(n)), чтобы избежать долгих операций."
Просто совет дня.
Можно ещё добавить старайтесь не использовать квадратичные и ни в коем случае не используйте экспоненциальные. И будет прямо как три закона роботехники.
Ну уберут из питона GIL, дадут всем дженерики, через пару лет за счёт этого создадут первый официальный компилятор питона в бинарник. И что получиться, голанг какой-нибудь...
Китайские мультитулы это конечно весело. Но когда нужно копьё, как запихать в карман копьё? Какого зверя идём бить - такой и инструмент берём.
Интересно кто-то думал, когда шёл в it, что вот сейчас курс по питону от Яндекса пройду вот и буду горы денег зашибать.
Упёрлись в gil - значит доросли до копья. И пора осваивать копьё.
С языками ещё и инфастуктурщина всякая липнет. Докеры, куберы, гитлабы, дженкинс. Чат жпт вот появился. Улучшайзеры, генераторы, идеешки, плагины, базы данных, ресурсы, мощности, хостинг...
Но почему то вот язык у большинства людей в голове он как то оторван вот от остального... Мол на одном языке продукт создам на 1000 000 пользователей... Ща вот освою питон и как жахну тикток+.
Изучил питон, освоил Джил. Иди го ковыряй. Упёрся в GC - иди rust ковыряй. Там упёрся в сложно понять куда - иди в ассемблер.
Чем раньше это будет понято, тем больше миру пользы. И обсуждений зачем создали Джил и для кого - станет меньше. Особенно советов питонистам, как его обходить. На первой строке такого совета должно быть "Открываем книжку по голангу".
Автор говорит о том, что GIL ограничивает выполнение CPU-bound задач, при этом демонстрируя пример с использованием модуля threading, который работает именно с потоками, которые никак не ускоряют их выполнение
Ну думаю, зайду, наконец-то почитаю КАК же все таки устоен GIL
Ответ - слишком сложно, это просто мьютекс... ага, ясно, понятно.
Спасибо за статью! Но остался вопрос: когда же все-таки выгодно использовать multithreading?
Как устроен GIL (Global Interpreter Lock) в Python: влияние на многозадачность и производительность