Comments 23
Полезные статьи, как минимум для общего развития, спасибо! Жаль только, что их читает мало людей, сам однажды писал статью о System P — очень мало заинтересованных :(
Интересно, а какие разработки и научные исследования проходят в России, да и вообще в СНГ? Я долго искал с кем бы поработать в процессе написания диссертации, в конце концов забил и ушел сопровождать сервера оператора мобильной связи))
Интересно, а какие разработки и научные исследования проходят в России, да и вообще в СНГ? Я долго искал с кем бы поработать в процессе написания диссертации, в конце концов забил и ушел сопровождать сервера оператора мобильной связи))
К сожалению я не в курсе, какие современные разработки идут в наших университетах и научных институтах — если кто-то владеет подобной информацией, я бы сам с удовольствием узнал подробности.
У нас есть работы над системой RIDE и суперкомпьютер K-100. Есть разработки специализированных процессорных архитектур для обработки сигналов, но там параллельность всегда специфичная.
Вспомнилось ещё Intel TBB — многие его части делают у нас, в Нижнем Новгороде. У них может быть в университете нечто такое этакое.
Не знаю как с заинтересованными людьми. Но системы такого уровня в России строятся.
habrahabr.ru/blogs/hi/135384/
А раз строят, да еще, как пишут, на своих разработках… специалисты и научная база должны быть в наличии.
habrahabr.ru/blogs/hi/135384/
А раз строят, да еще, как пишут, на своих разработках… специалисты и научная база должны быть в наличии.
под напряжением в 55 Ватт как то не логично? не?
Так в результате транзакционная память не работает в многопоточном режиме на этом самом BlueGene/Q?
Как это выглядит с точки зрения кодинга?
Вопросы возникают такие тут на самом деле.
1. А собственно, чем ситуация с бесконечным откладыванием (всегда успевает изменится версия данных) лучше взаимоблокировок? Ну будет livelock. С ними ещё сложнее бороться, чем с deadlock-ами. В последних хоть можно восстановить граф зависимостей, который приводит к останову, а тут?
2. Не понятно, что будет, если счётчики версий переполнятся. И хранятся ли они в RAM? Если хранятся, то это же будет дополнительное требование к ПСП, которого и так вечно не хватает. Если не хранятся, то это вообще как? Программист наделал ошибок — забил весь кэш транзакциями, и всё? Работа прекратилась?
3. Вообще-то уже достаточно давно показано, что общая память с изменяемыми извне состояниями — это тихий ужас для программирования. Тут дело совсем не в возможных блокировках или ошибках при синхронизации, дело в том, что очень сложно в таком случае формулировать инварианты алгоритма. Логическое время в программе мало того, что начинает течь нелинейно, оно вообще пропадает, невозможно сформулировать концепцию события. TM не помогает с этим никак совладать: появляется, конечно, событие: транзакция выполнена, но как его связать с общей системой событий в приложении? Не понятно, за счёт чего здесь облегчение будет достигнуто в программировании.
4. Sun же уже давно пыталась это сделать… Не выстрелило. И дело совсем не в том, что программная реализация неэффективна, а в том что сама абстракция неудобная для программирования. Вот если бы futures-ы получили аппаратную поддержку…
1. А собственно, чем ситуация с бесконечным откладыванием (всегда успевает изменится версия данных) лучше взаимоблокировок? Ну будет livelock. С ними ещё сложнее бороться, чем с deadlock-ами. В последних хоть можно восстановить граф зависимостей, который приводит к останову, а тут?
2. Не понятно, что будет, если счётчики версий переполнятся. И хранятся ли они в RAM? Если хранятся, то это же будет дополнительное требование к ПСП, которого и так вечно не хватает. Если не хранятся, то это вообще как? Программист наделал ошибок — забил весь кэш транзакциями, и всё? Работа прекратилась?
3. Вообще-то уже достаточно давно показано, что общая память с изменяемыми извне состояниями — это тихий ужас для программирования. Тут дело совсем не в возможных блокировках или ошибках при синхронизации, дело в том, что очень сложно в таком случае формулировать инварианты алгоритма. Логическое время в программе мало того, что начинает течь нелинейно, оно вообще пропадает, невозможно сформулировать концепцию события. TM не помогает с этим никак совладать: появляется, конечно, событие: транзакция выполнена, но как его связать с общей системой событий в приложении? Не понятно, за счёт чего здесь облегчение будет достигнуто в программировании.
4. Sun же уже давно пыталась это сделать… Не выстрелило. И дело совсем не в том, что программная реализация неэффективна, а в том что сама абстракция неудобная для программирования. Вот если бы futures-ы получили аппаратную поддержку…
Попытаюсь ответить на ваши вопросы в ближайшее время после консультации с сотрудниками IBM.
> 1. А собственно, чем ситуация с бесконечным откладыванием (всегда успевает изменится версия данных) лучше взаимоблокировок? Ну будет livelock. С ними ещё сложнее бороться, чем с deadlock-ами. В последних хоть можно восстановить граф зависимостей, который приводит к останову, а тут?
Можно делать несколько попыток и после n-ой неудачной, пойти по классической схеме и залочить необходимые ячейки. Но тогда уже нет гарантии от deadlock-а :).
> 3. Вообще-то уже достаточно давно показано, что общая память с изменяемыми извне состояниями — это тихий ужас для программирования. Не понятно, за счёт чего здесь облегчение будет достигнуто в программировании.
STM/HTM эмулирует нешаримую память. В идеале все выглядит так, будто бы ты единолично работаешь с памятью. Вариант share-nothing хорош, но у него есть свои недостатки — постоянные накладные расходы на копирование.
> 4. Sun же уже давно пыталась это сделать… Не выстрелило. И дело совсем не в том, что программная реализация неэффективна, а в том что сама абстракция неудобная для программирования. Вот если бы futures-ы получили аппаратную поддержку…
Почему неудобная? В Haskell и Clojure вроде как отлично работает. Даже Джо Армстронг(автор Erlang) сказал что из всех вариантов(кроме message-passing), STM самый многообещающий.
А у futures-ов есть свои проблемы с глобальным состоянием: calculist.org/blog/2011/12/14/why-coroutines-wont-work-on-the-web/
Можно делать несколько попыток и после n-ой неудачной, пойти по классической схеме и залочить необходимые ячейки. Но тогда уже нет гарантии от deadlock-а :).
> 3. Вообще-то уже достаточно давно показано, что общая память с изменяемыми извне состояниями — это тихий ужас для программирования. Не понятно, за счёт чего здесь облегчение будет достигнуто в программировании.
STM/HTM эмулирует нешаримую память. В идеале все выглядит так, будто бы ты единолично работаешь с памятью. Вариант share-nothing хорош, но у него есть свои недостатки — постоянные накладные расходы на копирование.
> 4. Sun же уже давно пыталась это сделать… Не выстрелило. И дело совсем не в том, что программная реализация неэффективна, а в том что сама абстракция неудобная для программирования. Вот если бы futures-ы получили аппаратную поддержку…
Почему неудобная? В Haskell и Clojure вроде как отлично работает. Даже Джо Армстронг(автор Erlang) сказал что из всех вариантов(кроме message-passing), STM самый многообещающий.
А у futures-ов есть свои проблемы с глобальным состоянием: calculist.org/blog/2011/12/14/why-coroutines-wont-work-on-the-web/
Эмс. Сопрограммы и фьючерсы — это всё же разные вещи.
Можно делать несколько попыток и после n-ой неудачной, пойти по классической схеме и залочить необходимые ячейки. Но тогда уже нет гарантии от deadlock-а :).
А есть оценка вероятностей (с этим всегда плохо) с которой мы будем попадать на локи? Тут, ведь, как… Если вероятности маленькие, значит, взаимодействие не особо интенсивное, значит, какая выгода от TM? Вроде, это всё можно посчитать, но я не встречал почему-то количественных оценок, только качественные.
STM/HTM эмулирует нешаримую память. В идеале все выглядит так, будто бы ты единолично работаешь с памятью. Вариант share-nothing хорош, но у него есть свои недостатки — постоянные накладные расходы на копирование.
Не понятное высказывание про эмуляцию. Состояние же передаётся между взаимодействующими задачами, почему в таком случае память неразделяемая? Ну… И оно с обычными критическими секциями выглядит так, что память только у одной задачи, просто вокруг танцы с бубнами для синхронизации. Но не в этом же основная проблема.
Кроме share-nothing есть ещё множество промежуточных вариантов: потоковые парадигмы, агенты, process calculus.
Почему неудобная? В Haskell и Clojure вроде как отлично работает. Даже Джо Армстронг(автор Erlang) сказал что из всех вариантов(кроме message-passing), STM самый многообещающий.
«Отлично» в каком смысле? Про Haskell я не знаю, наверное, там есть какая-нибудь библиотека (они вообще всё без разбора в библиотеки тянут), но насчёт качества её работы у меня сомнения, как и вообще по поводу всего, сделанного на Haskell.
В Clojure же, насколько я могу судить, то, что называется транзакционной памятью — это совсем не то, что обычно понимается под STM. Их вариант с синхронными ссылками более такой, эмс… ну, для него более на уровне интуиции ясно, почему он может быть удобнее и эффективнее критических секций обновляющих общую память.
Но и там, как мне кажется, нет того, что решает основную проблему с параллельными вычислениями. Потому как все эти очереди версий ссылок никак не связаны для программиста в некий поток событий, на который можно опереться в логике программы. В версии, которую видит программист, не закодировано никак ни то, что было до (это, впрочем, можно вручную добавит), ни то, что будет после этой версии (а вот это уже проблема).
Поэтому толку от того, что для каждой нити в критической секции обеспечивается консистентное состояние «мира» почти никакого нет, потому что главная-то сложность не в получении этого состояния (давно уже известно, как надо правильно локи лочить, чтобы взаимоблокировок не было, и давно известно как эти локи лочить эффективно), а в согласованном переходе между ними. И в возможности изменять независимо части этого мира, а потом собирать его в единое целое. Облегчает ли TM эти задачи? Лично мне кажется — совсем нет. Не даёт она механизма для организации потока событий.
В этом плане сообщения Erlang (которые, кстати, совсем не share-nothing: данные в них неизменяемые, и их можно не копировать) гораздо удобнее, потому что для них поток событий вполне себе формально определяем, виден из программы, его можно контроллировать и им можно пользоваться (часты Лампорта и всё такое прочее). Про futures-ы (promises, в терминологии Haskell) можно сказать то же самое.
IMHO, есть в TM какой-то элемент PR-а и рыночной технологии. Все знают про базы данных и про транзакционную модель, и на это можно опираться в маркетинговой компании: у Вас ещё нет процессора с поддержкой TM? — Тогда мы идём к Вам!
Можно делать несколько попыток и после n-ой неудачной, пойти по классической схеме и залочить необходимые ячейки. Но тогда уже нет гарантии от deadlock-а :).
А есть оценка вероятностей (с этим всегда плохо) с которой мы будем попадать на локи? Тут, ведь, как… Если вероятности маленькие, значит, взаимодействие не особо интенсивное, значит, какая выгода от TM? Вроде, это всё можно посчитать, но я не встречал почему-то количественных оценок, только качественные.
STM/HTM эмулирует нешаримую память. В идеале все выглядит так, будто бы ты единолично работаешь с памятью. Вариант share-nothing хорош, но у него есть свои недостатки — постоянные накладные расходы на копирование.
Не понятное высказывание про эмуляцию. Состояние же передаётся между взаимодействующими задачами, почему в таком случае память неразделяемая? Ну… И оно с обычными критическими секциями выглядит так, что память только у одной задачи, просто вокруг танцы с бубнами для синхронизации. Но не в этом же основная проблема.
Кроме share-nothing есть ещё множество промежуточных вариантов: потоковые парадигмы, агенты, process calculus.
Почему неудобная? В Haskell и Clojure вроде как отлично работает. Даже Джо Армстронг(автор Erlang) сказал что из всех вариантов(кроме message-passing), STM самый многообещающий.
«Отлично» в каком смысле? Про Haskell я не знаю, наверное, там есть какая-нибудь библиотека (они вообще всё без разбора в библиотеки тянут), но насчёт качества её работы у меня сомнения, как и вообще по поводу всего, сделанного на Haskell.
В Clojure же, насколько я могу судить, то, что называется транзакционной памятью — это совсем не то, что обычно понимается под STM. Их вариант с синхронными ссылками более такой, эмс… ну, для него более на уровне интуиции ясно, почему он может быть удобнее и эффективнее критических секций обновляющих общую память.
Но и там, как мне кажется, нет того, что решает основную проблему с параллельными вычислениями. Потому как все эти очереди версий ссылок никак не связаны для программиста в некий поток событий, на который можно опереться в логике программы. В версии, которую видит программист, не закодировано никак ни то, что было до (это, впрочем, можно вручную добавит), ни то, что будет после этой версии (а вот это уже проблема).
Поэтому толку от того, что для каждой нити в критической секции обеспечивается консистентное состояние «мира» почти никакого нет, потому что главная-то сложность не в получении этого состояния (давно уже известно, как надо правильно локи лочить, чтобы взаимоблокировок не было, и давно известно как эти локи лочить эффективно), а в согласованном переходе между ними. И в возможности изменять независимо части этого мира, а потом собирать его в единое целое. Облегчает ли TM эти задачи? Лично мне кажется — совсем нет. Не даёт она механизма для организации потока событий.
В этом плане сообщения Erlang (которые, кстати, совсем не share-nothing: данные в них неизменяемые, и их можно не копировать) гораздо удобнее, потому что для них поток событий вполне себе формально определяем, виден из программы, его можно контроллировать и им можно пользоваться (часты Лампорта и всё такое прочее). Про futures-ы (promises, в терминологии Haskell) можно сказать то же самое.
IMHO, есть в TM какой-то элемент PR-а и рыночной технологии. Все знают про базы данных и про транзакционную модель, и на это можно опираться в маркетинговой компании: у Вас ещё нет процессора с поддержкой TM? — Тогда мы идём к Вам!
UFO just landed and posted this here
К такой транзакционной памяти применим термин уровень изоляции транзакций, если да, то какой он или каковы его свойства?
>Ни один другой поток не может получить доступ к заблокированному значению пока текущий >поток не закончит процедуру — приходится курить и ждать.
Так есть модели локов, когда можно читать заблокированное значение, например в Java для этого даже отдельные типы данных сделали.
А если нужно постоянно их изменять, то транзакции здесь также не помогут, будут только зря процессор грузить и отменять транзакции…
В общем, не впечатляет. Актеры в Scala или на Java (Akka) меня больше впечатлили…
Так есть модели локов, когда можно читать заблокированное значение, например в Java для этого даже отдельные типы данных сделали.
А если нужно постоянно их изменять, то транзакции здесь также не помогут, будут только зря процессор грузить и отменять транзакции…
В общем, не впечатляет. Актеры в Scala или на Java (Akka) меня больше впечатлили…
Sign up to leave a comment.
Транзакционная память и многопоточность