?

Log in

СЯУ, что такое «Software Transactional Memory». В процессе поглядения… - Оживший юзерпик

Nov. 9th, 2012

07:41 pm

Previous Entry Share Next Entry

СЯУ, что такое «Software Transactional Memory». В процессе поглядения на Clojure.

Current Mood: working

Comments:

[User Picture]
From:besm6
Date:November 9th, 2012 04:45 pm (UTC)
(Link)
СЯУ, что такое СЯУ :)

А STM рулит, да. Не знаю, как в клозуре, а в хаскеле, где оно завернуто в специально обученную монаду, и потому сделать ошибку с ней крайне трудно, если вообще возможно, так удобно между тредами информацию гонять...
(Reply) (Thread)
[User Picture]
From:alexott
Date:November 9th, 2012 04:49 pm (UTC)
(Link)
btw, вот неплохая статья про stm/clojure. а так, если соберешься книжку читать какую-нибудь, то рекомендую Clojure Programming by O'Reilly, она хоть и толстая, но хорошая :-)
(Reply) (Thread)
[User Picture]
From:tobotras
Date:November 9th, 2012 06:06 pm (UTC)
(Link)
Ага, спасибо, но я обычно ленюсь книжки читать, когда есть stackoverflow :)
(Reply) (Parent) (Thread)
[User Picture]
From:oort
Date:November 9th, 2012 07:05 pm (UTC)
(Link)
Что характерно, я STM осознал тоже по кложуре. Видимо, она его пиарит.
(Reply) (Thread)
[User Picture]
From:tobotras
Date:November 9th, 2012 07:11 pm (UTC)
(Link)
Я так понимаю, что это кложура или хаскель. В других местах это костыли…
(Reply) (Parent) (Thread)
[User Picture]
From:sporadic_man
Date:November 10th, 2012 10:52 am (UTC)
(Link)
А чего для тебе кложура?
(Reply) (Thread)
[User Picture]
From:tobotras
Date:November 10th, 2012 11:04 am (UTC)
(Link)
Для расширения кругозора в основном. Ну, и, может, пригодится где. Надоело мне что-то на шелле скрипты писать.
(Reply) (Parent) (Thread)
[User Picture]
From:bludwarf
Date:November 10th, 2012 12:53 pm (UTC)
(Link)
Привет!

Относительно недавно писал про STM в GCC: http://natsys-lab.blogspot.ru/2012/05/software-transactional-memory-stm-in.html . В процессорах следующего поколения от Intel уже будет аппаратная поддержка.

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

Edited at 2012-11-10 12:54 pm (UTC)
(Reply) (Thread)
[User Picture]
From:tobotras
Date:November 10th, 2012 04:28 pm (UTC)
(Link)
Спасибо, погляжу!
(Reply) (Parent) (Thread)
[User Picture]
From:votez
Date:November 11th, 2012 09:39 pm (UTC)
(Link)
не в тему, но.... Из жвм языков СКАЛА РУЛИТ!!!
а про STM - акторы наше всё
(Reply) (Thread)
[User Picture]
From:tobotras
Date:November 12th, 2012 05:49 am (UTC)

Прокомментируй?

(Link)
"I chose not to use the Erlang-style actor model for same-process state management in Clojure for several reasons:

- It is a much more complex programming model, requiring 2-message conversations for the simplest data reads, and forcing the use of blocking message receives, which introduce the potential for deadlock. Programming for the failure modes of distribution means utilizing timeouts etc. It causes a bifurcation of the program protocols, some of which are represented by functions and others by the values of messages.
- It doesn't let you fully leverage the efficiencies of being in the same process. It is quite possible to efficiently directly share a large immutable data structure between threads, but the actor model forces intervening conversations and, potentially, copying. Reads and writes get serialized and block each other, etc.
- It reduces your flexibility in modeling - this is a world in which everyone sits in a windowless room and communicates only by mail. Programs are decomposed as piles of blocking switch statements. You can only handle messages you anticipated receiving. Coordinating activities involving multiple actors is very difficult. You can't observe anything without its cooperation/coordination - making ad-hoc reporting or analysis impossible, instead forcing every actor to participate in each protocol.
- It is often the case that taking something that works well locally and transparently distributing it doesn't work out - the conversation granularity is too chatty or the message payloads are too large or the failure modes change the optimal work partitioning, i.e. transparent distribution isn't transparent and the code has to change anyway."
(Reply) (Parent) (Thread)
[User Picture]
From:votez
Date:November 12th, 2012 05:56 am (UTC)

Re: Прокомментируй?

(Link)
лагко - кто-то принимает одну модель, а кто-то - другую. Для меня акторы более интересная тема, потому что она ближе к реальному миру, а не к базам данных - транзакционные состояния, все дела. Обмен же сообщениями является более чистым (на мой взгляд) функциональным подходом - в теории, а на практике (я думаю) - гораздо больше имеет шансов для горизонтальной масштабируемости.
Я с удовольствием использую параллельные примитивы и средства синхронизации и STM - это из той же области компьютерной науки, только с синтаксическим сахаром. Так что я выбираю новое веяние, just for fun в том числе
(Reply) (Parent) (Thread)
[User Picture]
From:votez
Date:November 12th, 2012 06:00 am (UTC)

Re: Прокомментируй?

(Link)
а, ну тут автор прямо в лоб говорит - двунаправленная передача данных в одном процессе. Это очень скучный (и не очень частый в моей практике) вариант, для него в скале свои альтернативы и акторы там не нужны. Это как сравнивать Hello World на консоли и в веб приложении.
(Reply) (Parent) (Thread)