LINUX.ORG.RU

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


0

0

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

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

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

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

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

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

www_linux_org_ru ★★★★★ ()

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

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

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

tailgunner ★★★★★ ()

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

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

www_linux_org_ru ★★★★★ ()

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

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

А поподробней?

www_linux_org_ru ★★★★★ ()

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

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

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

www_linux_org_ru ★★★★★ ()

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

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

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

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

tailgunner ★★★★★ ()

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

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

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

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

www_linux_org_ru ★★★★★ ()

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

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

imp ★★ ()

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

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

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

www_linux_org_ru ★★★★★ ()

Re: Кто видел полезность

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

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

DonkeyHot ★★★★★ ()
Ответ на: Re: Кто видел полезность от DonkeyHot

Re: Кто видел полезность

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

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

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