LINUX.ORG.RU
Форум — Development  

[haskell][c++] Кто видел полезность «функциональной STM» (в противовес процедурной STM) в реальных задачах?

 ,


0

0

Прочесть про STM можно хотя бы в википедии: http://en.wikipedia.org/wiki/Software_transactional_memory

Мы можем (грубо) выделить 2 подхода:

1. Функциональная STM: вместо того чтобы лочить память, мы производим над ней операцию, а побочный эффект этой операции, касающийся ВВ на диск, по сети и так далее система не применяет сразу же, а сохраняет в виде замыкания, монады и тому подобного. Если после окончания операции выяснится, что память не поменялась еще какой-то другой конкурирующей операцией, то мы "воспроизводим" сохраненный побочный эффект: пишем на диск, по сети и так далее. Если же выяснится, что память поменялась еще какой-то другой конкурирующей операцией, то мы выбрасываем сохраненный побочный эффект и "перезапускаем" операцию заново.

2. Процедурная STM: лочим память, делаем все что надо, разлочиваем память. Если вдруг кому-то в это время память требуется -- он стоит и ждет.

← shell Не работает скрипт
python httplib →

s/мы "воспроизводим" сохраненный побочный эффект/система "воспроизводит" сохраненный побочный эффект/

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

> Процедурная STM: лочим память, делаем все что надо, разлочиваем память. Если вдруг кому-то в это время память требуется -- он стоит и ждет.

Это не STM вообще.

tailgunner ★★★★★
()

Выбрасывает сохраненный побочный эффект и "перезапускает" операцию заново тоже не мы, а система.

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

>> Это не STM вообще.

> Ну да, я ничего не сказал про коммит и повторение транзакции...

И параллельность. У тебя параллельности вообще нет - данные прикрыты локом. Почитай лучше об RCU.

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

> И параллельность. У тебя параллельности вообще нет - данные прикрыты локом. Почитай лучше об RCUН

Ну тогда вопрос надо (пока что) поставить так:

Кто видел реальные задачи, где STM с сохраненным побочным эффектом удобнее, чем локи? Причем удобнее не потому, что использовался язык с хорошей поддержкой функционального стиля программирования (например хаскель), а потому, что такова специфика задачи?

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

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

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

> Это должно быть несложно оценить.

Согласен. Но хочется именно историю успеха STM послушать, и убедится, что локи там будут не таким хорошим решением.

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

>производим над ней операцию ... Если же выяснится ... перезапускаем" операцию заново

Безотносительно функциональщины, так делает довольно реальный Oracle RDBMS (если мне дбашник не соврал).

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

> Безотносительно функциональщины, так делает довольно реальный Oracle RDBMS (если мне дбашник не соврал).

Не соврал. Общая идея STM - это цельнотянутый MVCC. Кстати, так не только Оракул делает.

tailgunner ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← shell Не работает скрипт
Development
python httplib →