что один интерпретатор, то ему необходимо переключаться между потоками дабы выполнять их по очереди? Ну не совсем по очереди, а как-то переключаясь каждый раз?
гил это искусственное ограничение
ob->ob_refcnt не атомарен
В многотредовом коде нужно защищать общее состояние которое сразу несколько тредов одновременно меняют. В питоне решили что это общее состояние — интерпретатор целиком и нацепили на него GIL
но пользоваться threading.Lock все равно надо 🌚
ну оно защищают интерпретатор, а не пользовательский код
Как 3.13 может решить проблему или найти лучший компромисс? Говорят какие-то мультиинтеаритаторы или ещё что-то появится
Насколько я могу понимать, из-за того, что одно состояние главного потока может быть изменено сразу двумя тредами, то интерпретатор сначала останавливает один, даёт изменить состояние второму, а потом разблокирует второй для этого?
А гил я правильно понимаю в этом контексте??
Как будет реализация в мэйне расскажу
Неправильно понимаешь "состояние главного потока". Нет никакого главного потока и меняется не состояние потока, а состояние интерпретатора
А в остальном? Именно эту проблему пример которой я описал и решает Гил?
Просто мало ли. Решат Лок на арену делать :)
Ты как-то плохо описал все
Во первых, у нас мималок
У каждого объекта в питоне есть счётчик ссылок — число сколько объектов ещё ссылается на объект, когда этот счётчик равен нулю, то объект можно удалить. Изменение этого значения это на самом деле три отдельных операции: стянуть счётчик к себе, поменять вот это значение у себя на единицу, записать стянутое себе значение обратно в счётчик. И если два треда будут это делать одновременно, то они могут например оба стянуть "5", увеличить на 1, и записать "6", хотя должно быть 7 в итоге
щас немного вникаю во всю эту темную магию, по словам похоже на семафоры они?
если рефкаунтер в питоне это семафор, то хлопушки в молоке — это суп :)
Обсуждают сегодня