Модель Эраланга работает нормально только если нет разделения данных. А
если оно есть (например, если несколько потоков работают над одним
большим массивом) — то все становится плохо.
Можно попробовать сделать этот ресурс процессом — но опять получим все
те же проблемы с блокировками, но уже уровнем выше.
C>Если бы все было так легко...
C>Модель Эраланга работает нормально только если нет разделения данных. А C>если оно есть (например, если несколько потоков работают над одним C>большим массивом) — то все становится плохо.
А нельзя переструктурировать приложение таким образом, чтобы не было этого самого разделения?
И можешь сформулировать более приближенную к реальности задачу, которая бы не "втискивалась" в данную модель?
А если ресурс сделать процессом, то разве в Эрланге можно эти блокировки вообще реализовать стандартными способами? Насколько я понимаю посылка сообщений асинхронная и не обязательно гарантированная (хотя я скорей чайник в этом языке )
Здравствуйте, Курилка, Вы писали:
К>А нельзя переструктурировать приложение таким образом, чтобы не было этого самого разделения?
Если можно, в двух словах: как удается в Erlang избегать разделения в принципе?
Ведь, как правило, (хотя бы минимальное) разделение ресурсов имеет место быть.
Например, создаем новый процесс — откусываем ресурс (например, память) от общего пирога.
В то же самое время кто-то также пытается создать процесс.
По идее, надо ставить такие запросы в очередь. Следовательно — опять блокировки, мониторы и т.п.
Как же Erlang без этого обходится?
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
AVC,
К>>А нельзя переструктурировать приложение таким образом, чтобы не было этого самого разделения?
AVC>Если можно, в двух словах: как удается в Erlang избегать разделения в принципе? AVC>Ведь, как правило, (хотя бы минимальное) разделение ресурсов имеет место быть. AVC>Например, создаем новый процесс — откусываем ресурс (например, память) от общего пирога. AVC>В то же самое время кто-то также пытается создать процесс. AVC>По идее, надо ставить такие запросы в очередь. Следовательно — опять блокировки, мониторы и т.п. AVC>Как же Erlang без этого обходится?
Здравствуйте, Cyberax, Вы писали:
C>если оно есть (например, если несколько потоков работают над одним C>большим массивом) — то все становится плохо.
как я понял, в Эрланге делается по другому
нужно поделить "работу" на задачи и один процесс будет передавать данные другому для дальнейшей обработки
много процессов могут одновременно обрабатывать разные части большого массива
если процессу нужны данные из части массива которой у него нет, то он заправшивает и/или ждёт когда ему их пришлют
т.е. скорее всего нужна какая-то координация, кто что делает и какие кучки данных обрабатывает
Курилка wrote: > C>Модель Эраланга работает нормально только если нет разделения данных. А > C>если оно есть (например, если несколько потоков работают над одним > C>большим массивом) — то все становится плохо. > А нельзя переструктурировать приложение таким образом, чтобы не было > этого самого разделения? > И можешь сформулировать более приближенную к реальности задачу, которая > бы не "втискивалась" в данную модель?
Есть модель поверхности, она представлена в виде весьма сложной
структуры данных. Модель очень большая (гигабайты), так что стандартный
функциональный подход не проходит.
Разбить на процессы тоже очень сложно — так как поверхность в процессе
обработки сильно меняется.
> А если ресурс сделать процессом, то разве в Эрланге можно эти блокировки > вообще реализовать стандартными способами? Насколько я понимаю посылка > сообщений асинхронная и не обязательно гарантированная (хотя я скорей > чайник в этом языке )
Блокировки делаются просто — делаем потоку два сообщения "lock" и
"unlock". Если поток в состоянии locked, то сообщения от неправильных
клиентов он обрабатывать не будет.
Banch wrote: > C>если оно есть (например, если несколько потоков работают над одним > C>большим массивом) — то все становится плохо. > как я понял, в Эрланге делается по другому > нужно поделить "работу" на задачи и один процесс будет передавать данные > другому для дальнейшей обработки > много процессов могут одновременно обрабатывать разные части большого > массива если процессу нужны данные из части массива которой у него нет, то он > заправшивает и/или ждёт когда ему их пришлют
Так нету разделения на "части". В ходе обработки могут потребоваться
элементы из любой части массива.
А в силу своих размеров, массив нельзя копировать.
Здравствуйте, Cyberax, Вы писали:
C>Курилка wrote: >> C>Модель Эраланга работает нормально только если нет разделения данных. А >> C>если оно есть (например, если несколько потоков работают над одним >> C>большим массивом) — то все становится плохо. >> А нельзя переструктурировать приложение таким образом, чтобы не было >> этого самого разделения? >> И можешь сформулировать более приближенную к реальности задачу, которая >> бы не "втискивалась" в данную модель? C>Есть модель поверхности, она представлена в виде весьма сложной C>структуры данных. Модель очень большая (гигабайты), так что стандартный C>функциональный подход не проходит.
C>Разбить на процессы тоже очень сложно — так как поверхность в процессе C>обработки сильно меняется.
А на участки эту поверхность совсем не реально поделить, или необходим произвольный доступ для обработки?
Курилка wrote: > C>Разбить на процессы тоже очень сложно — так как поверхность в процессе > C>обработки сильно меняется. > А на участки эту поверхность совсем не реально поделить, или необходим > произвольный доступ для обработки?
Оно и так уже разделено, в несколько уровней (с индексами для доступа к
нужным элементам). Просто, например, алгоритмы поиска разломов запросто
могут полповерхности просмотреть.
Здравствуйте, Cyberax, Вы писали:
C>Так нету разделения на "части". В ходе обработки могут потребоваться C>элементы из любой части массива.
вот когда понадобяться, тогда и запрашивать их
хотя у меня подозрение, что не углубившись во все тонкости ответить тебе будет нереально
лучше попробуй сам подумать — можно ли как-то разделить задачу на параллельные процессы?
пока не пытаясь оптимизировать скорость и объём памяти до последней копейки
Banch wrote: > C>Так нету разделения на "части". В ходе обработки могут потребоваться > C>элементы из любой части массива. > вот когда понадобяться, тогда и запрашивать их
Что запращивать? У меня массив в 10000х10000 точек, с построенными на
нем "индексами" (деревьями, разбивающими массив на зоны по определенным
правилам). А еще из этого массива нужно для визуализации делать выборки
и т.п.
> лучше попробуй сам подумать — можно ли как-то разделить задачу на > параллельные процессы?
Можно. Сейчас это как раз делаю, но использую совершенно другой подход.
Все потоки имеют прямой доступ к дереву, а для предотвращения конфликтов
используется сложная система многоуровневых блокировок.
> пока не пытаясь оптимизировать скорость и объём памяти до последней копейки
Если не оптимизировать — оно просто работать не будет. Посчитай объем
памяти для такого массивчика.
Banch wrote: > C>Просто, например, алгоритмы поиска разломов запросто > C>могут полповерхности просмотреть. > может тут подойдёт MapReduce, который в Google применяют?
Нет. Так как каждый элемент массива сам по себе бессмысленен.
>> C>Так нету разделения на "части". В ходе обработки могут потребоваться >> C>элементы из любой части массива. >> вот когда понадобяться, тогда и запрашивать их C>Что запращивать? У меня массив в 10000х10000 точек, с построенными на C>нем "индексами" (деревьями, разбивающими массив на зоны по определенным C>правилам). А еще из этого массива нужно для визуализации делать выборки C>и т.п.
>> лучше попробуй сам подумать — можно ли как-то разделить задачу на >> параллельные процессы? C>Можно. Сейчас это как раз делаю, но использую совершенно другой подход.
C>Все потоки имеют прямой доступ к дереву, а для предотвращения конфликтов C> используется сложная система многоуровневых блокировок.
>> пока не пытаясь оптимизировать скорость и объём памяти до последней копейки C>Если не оптимизировать — оно просто работать не будет. Посчитай объем C>памяти для такого массивчика.
Это, по-моему, называется "впихнуть невпихуемое" Возможно, единственным решением такой проблемы таки является "прямой доступ к дереву, а для предотвращения конфликтов используется сложная система многоуровневых блокировок."
Mamut wrote: >> > пока не пытаясь оптимизировать скорость и объём памяти до последней > копейки > C>Если не оптимизировать — оно просто работать не будет. Посчитай объем > C>памяти для такого массивчика. > Это, по-моему, называется "впихнуть невпихуемое"
Впихиваемое, впихиваемое У меня же работает.
> Возможно, единственным > решением такой проблемы таки является "прямой доступ к дереву, а для > предотвращения конфликтов используется сложная система многоуровневых > блокировок."
Это просто другой способ организации многопоточных приложений, иногда
гораздо более эффективный, чем изолированные процессы.
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
AVC>>Если можно, в двух словах: как удается в Erlang избегать разделения в принципе? AVC>>Ведь, как правило, (хотя бы минимальное) разделение ресурсов имеет место быть. AVC>>Например, создаем новый процесс — откусываем ресурс (например, память) от общего пирога. AVC>>В то же самое время кто-то также пытается создать процесс. AVC>>По идее, надо ставить такие запросы в очередь. Следовательно — опять блокировки, мониторы и т.п. AVC>>Как же Erlang без этого обходится?
LCR>dets, mnesia
Excuse me?
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Здравствуйте, Курилка, Вы писали:
К>Собственно об этом говорит Джо Армстронг, описывая модель многозадачности в Эрланге.
Мне показалось, что конекретно это сообщение об Erlang-е весьма поверхносное, популистское и в большей степени рекламное. Хотя оно и понятно
К сожалению, там не говорится, что если строить все взаимодействие на сообщениях, то временами получается весьма геморройно. Хотя у меня не Erlang-овский опыт, но все же.
Так что параллелизм -- это, все таки, не легко.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
)
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
Возможно, единственным решением такой проблемы таки является "прямой доступ к дереву, а для предотвращения конфликтов используется сложная система многоуровневых блокировок."
