Закончил перевод статьи Эдварда Ли "Проблемы с потоками" (The Problem With Threads). Автор работает в калифорнийском университете Беркли и возглавляет проект Ptolemy Project, посвящённый моделированию распределённых, параллельных систем, встроенных систем и систем реального времени. Сам проект имеет долгую историю, реализация системы открыта и хорошо описана. Язык реализации — Java.
Статья посвящена обзору современного параллельного программирования и проблемам использования потоков(threads). Автор последовательно доказывает свою точку зрения — потокам не место в разработке параллельных приложений. При этом он приводит как чисто формальные аргументы с точки зрения теории вычислений, так и показывает какие проблемы использования потоков возникают на практике.
В статье дан обзор и оценка различных способов разработки параллельных приложений, способов, основанных не на потоках. По мнению автора самым перспективным с практической точки зрения подходом к разработке является создание координационных языков (coordination languages).
Статья была ранее опубликована в журнале IEEE Computer. Обзор статьи, сделанный Сергеем Кузнецовым(который делает регулярные обзоры выпусков IEEE Computer) Вы можете найти здесь, кроме того обзор данной статьи уже обсуждался на RSDN — тут.
На мой взгляд, обзор не даёт полного представление о статье, поэтому и появился этот перевод.
Это всё расчудесно. Я не очень понял только, где сам координационный язык? Или хотя бы прототипчик. Или хотя бы идея прототипчика. Или будем программировать диаграмками?
Я не вижу детального обсуждения разумных примитивов. (Активные) объекты, обменивающиеся сообщениями, — это известная и более-менее распространенная модель. А рандеву? Это примитив? Тогда как с ними программировать? Я могу бездумно собирать из мини-рандеву большие конструкции безопасным для скорости исполнения образом? И какие вообще гарантии эффективности механизм рандеву даёт?
Здравствуйте, deniok, Вы писали:
D>Это всё расчудесно. Я не очень понял только, где сам координационный язык? Или хотя бы прототипчик. Или хотя бы идея прототипчика. Или будем программировать диаграмками?
Здравствуйте, A.Lokotkov, Вы писали:
D>>Это всё расчудесно. Я не очень понял только, где сам координационный язык? Или хотя бы прототипчик. Или хотя бы идея прототипчика. Или будем программировать диаграмками?
AL>Coordination Models and Languages
Интересно, какого года эта работа? Судя по тому, что в списке литературы самая молодая публикация датируется 1997-м годом, то где-то район 97-98-м. Довольно древнее описание, имхо.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Интересно, какого года эта работа? Судя по тому, что в списке литературы самая молодая публикация датируется 1997-м годом, то где-то район 97-98-м. Довольно древнее описание, имхо.
Это обзор проблемы и вариантов решения. Для затравки.
Интересующиеся найдут что-нибудь посвежее, если смогут.
Здравствуйте, A.Lokotkov, Вы писали:
E>>Интересно, какого года эта работа? Судя по тому, что в списке литературы самая молодая публикация датируется 1997-м годом, то где-то район 97-98-м. Довольно древнее описание, имхо.
AL>Это обзор проблемы и вариантов решения. Для затравки. AL>Интересующиеся найдут что-нибудь посвежее, если смогут.
Не обижайтесь, пожалуйста, я не в упрек. Спасибо за ссылку, я обязательно просмотрю документ на досуге.
Просто 10-ть лет -- это очень большой срок в индустрии. За это время много чего могло измениться. И возраст публикации нужен для того, чтобы понимать, на данный ли момент там описыватся ситуация, или так было десять лет назад.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
E>Просто 10-ть лет -- это очень большой срок в индустрии. За это время много чего могло измениться. И возраст публикации нужен для того, чтобы понимать, на данный ли момент там описыватся ситуация, или так было десять лет назад.
Там же есть ссылка на java.util.concurrent из java 5 и заметка, что принципиально проблему это не решает. Так что можеш считать, что это адаптированный вариант
Здравствуйте, A.Lokotkov, Вы писали:
AL>Это обзор проблемы и вариантов решения. Для затравки. AL>Интересующиеся найдут что-нибудь посвежее, если смогут.
Я, вот, почти полный профан в этой области, но когда мне говорят "Давайте забудем о потоках" (основной тезис исходной статьи), я с радостью кричу "Давайте!", и смотрю что взамен. Любому хочется программировать n-процессорную систему с (n>>1), не думая в терминах взаимодействия потоков и общеизвестных примитивов их синхронизации. Я единственное, что хочу увидеть — это более высокоуровневые примитивы, которые однако же гарантируют мне загрузку пусть не 100% процессоров 100% времени, но хоть 30%*30%. Но не вижу.
Здравствуйте, eao197, Вы писали:
E>Просто 10-ть лет -- это очень большой срок в индустрии. За это время много чего могло измениться. И возраст публикации нужен для того, чтобы понимать, на данный ли момент там описыватся ситуация, или так было десять лет назад.
И не думал обижаться. У автора на страничке эта публикация датирована 1998 г. В индустрии за прошедшее время в этой области особых сдвигов не видно. Поэтому периодически появляются статьи о том, как муторно делать системы на thread-ах и пр.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Здравствуйте, eao197, Вы писали:
ANS>
E>>Просто 10-ть лет -- это очень большой срок в индустрии. За это время много чего могло измениться. И возраст публикации нужен для того, чтобы понимать, на данный ли момент там описыватся ситуация, или так было десять лет назад.
ANS>Там же есть ссылка на java.util.concurrent из java 5 и заметка, что принципиально проблему это не решает. Так что можеш считать, что это адаптированный вариант
Андрей, ссылка на Java 5 есть в работе The Problem With Threads, которую перевел Didro (еще раз спасибо).
Я же говорю про Coordination Models and Languages, на которую указал
A.Lokotkov. В последней работе, вышедшей, кстати, в 1998-м, дается обзор на момент 1997-го года. Может быть за это время ничего принципиально не изменилось, но добрая половина упомянутых в обзоре языков, думаю, давно канула в Лету.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, deniok, Вы писали:
D>Здравствуйте, A.Lokotkov, Вы писали:
D>Я, вот, почти полный профан в этой области, но когда мне говорят "Давайте забудем о потоках" (основной тезис исходной статьи), я с радостью кричу "Давайте!", и смотрю что взамен. Любому хочется программировать n-процессорную систему с (n>>1), не думая в терминах взаимодействия потоков и общеизвестных примитивов их синхронизации. Я единственное, что хочу увидеть — это более высокоуровневые примитивы, которые однако же гарантируют мне загрузку пусть не 100% процессоров 100% времени, но хоть 30%*30%.
Но не вижу.
Если не касаться координационных языков, то...
вообще систем\языков для высокоуровневого параллельного программирования навалом. Опять же большинство известных(мне) были перечислены в статье Ли, это Erland, Ada(A# = Ada.NET, кстати реализация рандеву есть именно в Ada), Google's Map\Reduce, Cilk, MPI, OpenMP,...В Scala, на сколько я знаю, есть средства для реализации акторов на потоках. В Nemerle на макросах релизовали join-модель паралл.вычислений. Некоторое представление об объёме сегмента подобных систем есть тут и тут (материалы с сайта parallel.ru). В мейнстриме же по мнению Э.А.Ли широко используются только потоки(с этим можно спорить и т.д.). При этом скажем в MS Research разрабатывался одно время Polyphonic C# / C_omega. У нас на базе .NET делают MC# (Multiprocessor C#). В тоже время на последней конференции Интела(в СПб) ничего кроме хороших профайлеров, отлаженных библиотек-распараллеленых примитивов, и прочих вещей для работы непосредственно с потоками не было... Но, вообщем, выбор есть.
В группе Ли разработана(и развивается до сих пор) система моделирования Ptolemy — те самые кубички . Кубички кстати свою роль оч.хорошо выполняют — программист(или в случае Ptolemy это будет скорей специалист прикладной области) вообще не думает о потоках, он работает с сущностями по законам выбранной модели параллелизма. Можно ещё отметить, что по одной из трактовок ООП развивалось из моделирования, в этом смысле Ptolemy может дать толчок для развития параллельного программирования.
Здравствуйте, eao197, Вы писали:
E>Просто 10-ть лет -- это очень большой срок в индустрии. За это время много чего могло измениться.
В проблематике за это время ничего не изменилось. Но появилась реальная потребность в распараллеливании не только на серверах, но и в обычном ПО.
По сути появилась здача ускорять выполнение ПО за счет распараллеливания. А раньше она была не актуальна.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, deniok, Вы писали:
D>Я, вот, почти полный профан в этой области, но когда мне говорят "Давайте забудем о потоках" (основной тезис исходной статьи), я с радостью кричу "Давайте!", и смотрю что взамен. Любому хочется программировать n-процессорную систему с (n>>1), не думая в терминах взаимодействия потоков и общеизвестных примитивов их синхронизации. Я единственное, что хочу увидеть — это более высокоуровневые примитивы, которые однако же гарантируют мне загрузку пусть не 100% процессоров 100% времени, но хоть 30%*30%. Но не вижу.
D>Я слишком много хочу?
Мне кажется общее решение лежит на поврехности. Все что я прочел за это время предлагало только одно. Отказаться от синхронизации управления и перейти к синхронизации данных.
Ну, а реализации тут могут быть самым разными. Посылка сообщений в очереди (Эрланг и Сингулярити), Рандеву (АДА... плохо понимаю смысл этого дела, но чувствую, что суть та же), Активные объекты (Оберон и что там еще?), STA-апартаменты в COM, использование разных процессов ОС.
Так как данные синхронизируются тем или иным образом потоки управления получаются изолированными и работающими независимо. Ну, а изоляцию данных легко позволяют организовать типобезопасные языки или среды исполнения.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Ну, а реализации тут могут быть самым разными. Посылка сообщений в очереди (Эрланг и Сингулярити), Рандеву (АДА... плохо понимаю смысл этого дела, но чувствую, что суть та же), Активные объекты (Оберон и что там еще?), STA-апартаменты в COM, использование разных процессов ОС.
Оберон и... Зоннон. То, что в Сингулярити, сильно напоминает мне Зоннон.
STA в COM – это в аккурат пассивный монитор.
Если на пальцах, то в Аде у каждой точки входа своя очередь. Причём ожидающие задачи могут взять и передумать, не дождавшись, выйти из середины очереди. Каналы Эрланга же подразумевают линейность потока сообщений.
Если задача была не занята, и точка входа открыта, вызов происходит как у объектов, не считая накладных расходов по закрыванию точек входа.
В Эрланге сообщения асинхронные, в Аде вызовы рандеву длятся, пока не кончится блок accept. С другой стороны, в блоке accept можно оставить себе данные и работать дальше.
task body Demo is
loop
[...]
declare
MyNumber : Integer;
MyResult : Integer;
begin
accept StartCalc (Number : in Integer) do
MyNumber := Number;
end StartCalc;
[...]
accept GetResult (Result : out Integer) do
Result := GetResult;
end GetResult;
end;
[...]
end loop;
end Demo;
Здравствуйте, OCTAGRAM, Вы писали:
OCT>Оберон и... Зоннон. То, что в Сингулярити, сильно напоминает мне Зоннон.
Ты не разобрался либо в сингулярити, либо в зононе, либо и в том и в другом.
Принципиальное отличие в том что протокол в сингулярити навешивается на канал, а в зонноне на активность.
Данное отличие сводит практически к нулю приминимость зоннона. Ибо очень много задач где у активности должно быть несколько каналов общения.
Болие того иногда колличество каналов задается из конфига, а иногда и вобще определяется во время работы.
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
