LINUX.ORG.RU

В кои-то века родил статью по своей питоновой либе

 ,


2

1

https://habr.com/en/post/526002/ — Making python's dream of multithreading come true

Хотелось написать что-то для прочтения буграм, но и вам запощу, так и быть. Буду благодарен, если кто-то запостит это на reddit.com/r/python и даст ссыль сюда, потому что мне еще две недели нужно ждать, пока аккаунту разрешат делать посты.

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

В частности, написание статьи само по себе помогло сообразить, что без механизма каналов особо нечего ловить в прикладнухе. Причем, я уже знаю, как эти каналы можно сделать гибкими на зависть Go-шникам, потому что это будет не прибитый гвоздями к языку черный ящик, а отдельные примитивы синхронизации и хранилище аля std::deque, для которого можно как быстро в lock-free режиме добавлять и забирать записи, так и выполнять на самом питоне сложные транзакции плана «выбрать записи определенного типа из очереди» — не блокируя при этом lock-free добавление новых сообщений и не блокируя параллельных читателей. То есть, в одном флаконе умещаются любые сочетания взаимодействий производитель-потребитель. Конечно, я подозреваю, что алгоритмы на питоне будут тормознутыми, но что ж поделать, это питон.

★★★★

Последнее исправление: byko3y (всего исправлений: 2)

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

Не всегда важно чтобы быстро работало, иногда важно чтобы быстро разрабатывать и тут с питоном только js тягаться может. Побочка в виде «Шаг – влево, шаг – вправо – побег! Прыжок на месте – провокация! Стреляю – без предупреждения» это не последствия того что питон плохой, а того что на нём из-за скорости разработки часто решается не задача сделать коммерческую версию софта, а задача быстрого запила прототипа/показ доказательства какой-либо теории, что так можно.

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

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

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

Владимир

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

Это плохие, негодные разработчики. Проект ИМХО гораздо важнее инструментов и технологий, потому что он является целью, а язык всего лишь способ её достижения.

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

Это плохие, негодные разработчики. Проект ИМХО гораздо важнее инструментов и технологий, потому что он является целью, а язык всего лишь способ её достижения.

Хотя конечно, кто «язык программирования не настругал», тот в Пекине не бывал.

Владимир

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

Второй поток может по завершении транзакции проверить, были ли изменены данные первым потоком и, если изменение было, то делать рестарт

Да, это ленивая модель нормального выполнения. Если быть точным, то ленивость/бойкость может быть разная для нормального выполнения и для разрешения конфликтов. Так вот: что делать, когда конфликт был обнаружен? Я описывал в статье проблему ленивых транзакций при интенсивных конкуренциях задач — в таких ситуациях ленивость при решении конфликтов отвратительнейше работает.

Хотя не совсем ясно, как обойтись без локов в конце транзакции, когда копия данных переносится в источник

Первый исторически документ, который описывал транзакционную память, предлагал использовать атомарный compare-and-swap на единственном указателе на данные. Все варианты compare-and-swap над несколькими ячейками и аппаратных транзакций в итоге сводятся к атомарному изменению единственной ячейки и спинлокам при конфликтах.

Если у второго потока есть какой-то дополнительный побочный эффект, то рестартовать его может быть непросто. Даже если не брать случай с запуском ракеты, то даже какое-нибудь обновление экрана с периодическими мелькающими артефактами вызовет вопросы у пользователя

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

То, что могут откуда ни возьмись появиться побочки — да, это проблема, и ей нужно уделять внимание. Я думаю, что случайных повторов транзакций для целей отладки будет достаточно — тем более, что для питона характерна test-driven разработка.

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

Есть такое в героях? Из того, что я смотрел, я видел ручное задание кол-ва дней с параллельными ходами. рестарт хода выглядит странно, потому что тогда в преимущественном положении оказывается тот, кто быстрее походил и больше узнал о карте.

Я не привязываю мои рассуждения к питону, так как считаю, что он не требовал изменений после версии 2.7. Соответственно, мне уже не важно, кто и что делает с современной версией

Да, не требовал. Но разрабатываемый мной проект довольно бесполезен для какого-то лиспа или другого языка на базе неизменяемых структур данных (в статье приведен пример Clojure). Для статически компилируемых быстрых языков, вроде C/C++, уже есть решения, так что для них мой проект тоже неактуален. Он актуален для медленных языков с требованием гарантий надежности выполнения самого кривого кода — а это Python, PHP, Perl, Ruby, Lua, и прочая скриптовуха.

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

двойная буферизация

Да, пока мы рисуем в памяти может прийти отбой из первого потока. А может и не успеть прийти, тогда из памяти всё перенесётся на экран. Таким образом двойная буферизация только снижает вероятность проблемы, но не устраняет полностью.

Есть такое в героях?

https://youtu.be/K96FFWGXFzY?t=1907 (время 31:47 примерно)

Читайте сообщение внизу экрана:

<СИСТЕМА>: Simultaneous Turns interrupted.
You have to replay last day.

Вокруг этого сообщения игрок дважды ведёт осаду замка.

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

Для справки: Ъ - это те, кто не ходит по ссылкам.

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

Да, пока мы рисуем в памяти может прийти отбой из первого потока

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

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

Двойной буфер рисует только законченную картинку.

Интересен был бы тред для обсуждения эффективности использования структур данных и в частности STL.

PS: Эти вопросы не такие уж «тривиальные» …
Некоторые все сводят к: «выравниванию», «вставках», …, а проблем много больше.

Владимир

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