LINUX.ORG.RU

Реализация PyPy языка Python избавляется от глобальных блокировок

 , ,


0

1

Глобальные блокировки в CPython (стандартная реализация языка python) долгое время были камнем преткновения и предметом многочисленных споров. В реализации PyPy, до недавнего времени, была применена схожая техника разграничения доступа к общим данным.

В настоящее время команда разработчиков проекта PyPy работает над альтернативным алгоритмом разграничения доступа к общим данным. Вместо блокировок предлагается использовать транзакции по аналогии с базами данных.

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

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

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

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

>>> Подробности

★★★★★

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

что-то он темнит

So, when will it be done? I cannot say yet. It is still at the idea stage, but I think that it can work. How long would it take us to write it? Again no clue, but we are looking at many months rather than many days. This is the sort of thing that I would like to be able to work on full time after the Eurostars funding runs out on September 1.

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

> А как они будут помечать начало и конец транзакции?

В смысле? Там идея в том чтобы производить изменения не в реальной памяти а в буфере. После внесения изменений данные из буфера накатываются на память.


Или вопрос в том как оно узнает что другая транзакция не была накатана? Есть несколько способов, обо всех них я узнал из википедии. Лучше я своими словами это пересказывать не буду и отправлю к оригиналу: http://en.wikipedia.org/wiki/Software_transactional_memory

Кстати, там сказано что уже для питона что-то реализовали, но я не разбирался что.

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

что-то он темнит

почему же, наоборот намекает что ему нужен грант т.к. старый скоро заканчивается :)

true_admin ★★★★★
() автор топика

>В настоящее время комманда разработчиков проекта PyPy работает над альтернативным алгоритмом разграничения доступа к общим данным

Когда сделают, тогда и постите новость.

elverion
()

the translation step «insert STM logic» is never going to be mandatory. You will get either a regular pypy-c-gil or a pypy-c-stm, as two different executables, and you will choose the one most suited for your particular program

Не взлетит.

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

> В смысле?

Ок, перефразирую вопрос. Допустим, в одном из потоков выполняется некий участок кода. Начало и конец очередной транзакции в этом коде должны быть отмечены вручную? Или оно само решает, на сколько и каких транзакций выполнение этого кода нужно разбить?

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

> Начало и конец очередной транзакции в этом коде должны быть отмечены вручную?

Да.

Или оно само решает, на сколько и каких транзакций выполнение этого кода нужно разбить?

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

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

Не взлетит.

наоборот. Там же оверхед гигантский для однопоточных приложений. Поэтому лучше иметь два варианта. Как раз с коллегами обсуждали это.

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

> лучше иметь два варианта.

При «гигантском оверхеде» оно вообще не нужно; а с двумя вариантами оно еще и останется неотлаженным (поскольку все будут пользоваться вариантом без STM).

tailgunner ★★★★★
()

Всё прекрасно, вот только сделали бы поддержку уже полную твистеда да джанго, цены бы не было. (А вообще, последнее время наслаждаюсь ерлангом)

Binary ★★★★★
()

А для Debian есть? А то что-то его в репозитории не видно.

terminator
()

Не новость это. Если о каждой идее, которую еще никто даже не начал планировать реализовывать, писать на ЛОРе, то через неделю жесткий диск переполнится!

provaton ★★★★★
()

Можно поправить новость, написав в чердаке что в PyPy хотят сделать STM? Ну и в метки поставить, событие довольно важное.

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

ну это понятно

просто у нас тут сейчас жарко :-)

важно когда они намерены эту работу завершить и как это будет в конце концов реализовано

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

В эрланге процессы никогда не ждут сообщения чтоб продолжить работу?

provaton ★★★★★
()

написал большой пост о том, почему не взлетит, и упал Фокс. так вот, не взлетит, инфа 100%

val-amart ★★★★★
()
Ответ на: комментарий от tailgunner

Ты правда думаешь, что в Erlang нет блокировок?

Увы нет, но я этого и не утверждал. При отказе от прямой изменяемости данных, отсутсвии каких-либо глобальных переменных и высокой изолированности процессов, разделяемые объекты и блокировки к ним не становятся головной болью, как это сейчас происходит в питоне/жабе/итд.

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

> При отказе от прямой изменяемости данных, отсутсвии каких-либо глобальных переменных и высокой изолированности процессов, разделяемые объекты и блокировки к ним не становятся головной болью, как это сейчас происходит в питоне/жабе/итд

За исключением «прямой изменяемости данных», всё это реализуемо и в Питоне/Жабе/Си. А в топике речь идет вообще о другом - о реализации исполняющей системы для Питона.

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

За исключением «прямой изменяемости данных», всё это реализуемо и в Питоне/Жабе/Си. А в топике речь идет вообще о другом - о реализации исполняющей системы для Питона.

Всё реализуемо. Всё и везде. А в топике речь вообще о другом - о реализации системы костылей к инвалиду от рождения.

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

> речь вообще о другом - о реализации системы костылей к инвалиду от рождения.

В то, что ты специалист по инвалидам от рождения, я верю сразу :D

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

многопоточные и без блокировок.

хаха.

Неужели вы думаете, что если один процесс ждет сообщения от другого процесса, то это принципиально отличается от ожидания освобождения мютекса в сишной программе?

Мне безусловно намного больше импонирует реализация многопоточности в эрланге, но говорить что в ней отстутствуют блокировки это нечестно и унизительно, потому что многопоточность без блокировок (без возможности остановить другой процесс, грубо говоря) зачастую просто бесполезна.

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

> Посмотрите на Erlang. там все приложения многопоточные и без блокировок.

Еще один... Просто атака экспертоты какая-то.

rtvd ★★★★★
()

Ну вот, уже MESI протокол в пистон лепят... Ну дятлы...

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

> Я думал, что тролли, которые скажут, что в хаскеле это было уже давно, прибегут попозже :)

<troll>И кстати, в хаскеле STM таки работает. Причем чудесно. В отличии от ...</troll>

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

Можно поправить новость

после утверждения править не могу :(

что в PyPy хотят сделать STM?

Слово pypy там есть, ну а stm пало жертвой литературной адаптации :(. Да, надо было куда-нить воткнуть для тех кто в теме.

Кстати, про менеджер транзакций это была отсебятина :). Но идея в первом приближении неплохая. Надо будет написать авторам pypy.

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

> Слово pypy там есть, ну а stm пало жертвой литературной адаптации

Не стоит увлекаться адаптацией, а то PyPy в ПиПи превратиться таким образом может ;)

tensai_cirno ★★★★★
()

Забыл добавить, мну стыдно за пунктуацию :(. Но теперь я уже исправить её не могу.

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

PyPy в ПиПи превратиться таким образом может ;)

Это уже не адаптация, это кривое заимствование :).

true_admin ★★★★★
() автор топика

А кто-нибудь понял, как оно будет перезапускать транзакции с сайд эффекатами?

dizza ★★★★★
()

пусть напишут, поговорим.

t184256 ★★★★★
()

А я не верю в STM. Ведь по сути это тот же мютекс, только вид сбоку. Да. тут отсутствует явный лок и анлок, который приводит к дедлокам, но по прежнему два треда бьющиеся за один участок памяти могут делать это с солидным оверхедом. И чем больше этот участок памяти, тем больше шанс коллизий и тем больше оверхед.

Ну авторам PyPy виднее чо, посмотрим что сделают.

nsf
()

>транзакционной памятью

Неизбежен отсос по всем фронтам, как и во всех остальных попытках реализовать STM на императивных выблевах.

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

> А кто-нибудь понял, как оно будет перезапускать транзакции с сайд эффекатами?

Читаем что такое STM. Транзакция не может быть с сайд эффектом.

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

по сути это тот же мютекс, только вид сбоку

Нуу, тут есть нюансы. Я бы назвал это мютексом на страницу памяти, а это многое может поменять.

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

А лучше видеть аппаратную поддержку такого в процах :).

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

По определению транзакции можно откатывать. Если транзакцию невозможно откатить — это уже не транзакция. Сайд-эффекты делать после коммита.

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

Ну а что, если они есть? Как выкручиваться?

Тогда будут проблемы. И такая ситуация вполне возможна. Где-то я читал про это вчера, но не всомню :(. Возможно на википедии.

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

По определению транзакции можно откатывать.

STM это software transactional memory. Оно касается только памяти. А вот io оно не касается. Поэтому если есть сайд-эффекты то будут проблемы при откате.

Сайд-эффекты делать после коммита.

Вот тогда придём к тому что сейчас уже есть. И, похоже, те вещи что нельзя откатывать должны исполнятся в один поток. Это значит что PyPy будет должен определять какие участки кода можно отдать под STM а какие придётся по старинке с локами организовывать. Пока я вижу только такое решение.

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