Здравствуйте, Mamut, Вы писали:
M>Во-первых, ты утвердаешь, что ничего, кроме мьютексов нет. Это не так. Второе. Мне интересно, сколько времени у тебя уйдет на реализацию http://learnyousomeerlang.com/supervisors когда все, что у тебя предлагает язык, — это мьютексы.
M>А так да. Читать в этом топике умеют единицы, потому что обо всем этом я уже написал.
Точнее аргументы у тебя говно. neFormal, Синклер и тд уже нескольким показывали, где ошибка в том подходе, что у Elazin, у них получилось.
А вот ты продолжаешь "куридопосинения" и "неумеешьчитать"
Re[9]: Эрланг и все-все-все (на самом деле, не совсем)
M>А так да. Читать в этом топике умеют единицы, потому что обо всем этом я уже написал.
Ты видимо не входишь в их число, так как я не утверждал что кроме мьютексов ничего нет. M>Во-первых, ты утвердаешь, что ничего, кроме мьютексов нет.
M>Во-первых, ты утвердаешь, что ничего, кроме мьютексов нет. Это не так. Второе. Мне интересно, сколько времени у тебя уйдет на реализацию http://learnyousomeerlang.com/supervisors когда все, что у тебя предлагает язык, — это мьютексы.
Во первых, я предложил реализовать какой-нибудь параллельный алгоритм (на erlang-е же можно их писать, да?), а не часть erlang-а. Слабо написать параллельный счетчик например, ну или CM-sketch? Мне не очевидно, что erlang может быть полезен для решения параллельных задач, с которыми мне приходилось сталкиваться в реальной жизни. Слабо верится что с его помощью можно даже простые статистические свойства потока сообщений приходящих на сервер оценить, я уже молчу о какой-нибудь более сложной обработке.
Во вторых, твои любимые супервайзеры имеют смысл только в языке с теми же свойствами что и erlang, процесс упал, мы его рестартанули и все, процесс продолжил потреблять очередь. В языке с общей памятью таск может упасть не из-за того что лежит в очереди а из-за того что лежит в этой самой общей памяти. Принцип let it fail тут применять не принято. В общем, вижу это как продолжение слива, решил предложить то что никто не возьмется делать и то что в erlang-е уже есть.
Re[6]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, ELazin, Вы писали:
EL>Не мьютексы сами по себе, а масштабируемые алгоритмы на них построенные. Сами мьютексы тоже не так просты как кажутся. В операционной системе тоже есть шедулер, прямо как в Erlang-е, который умеет шедулить потоки (которые прямо как Erlang-овские зеленые потоки в некотором смысле). Так вот, этот шедулер знает о том какие потоки блокируют друг друга, он знает приоритеты потоков и умеет их менять динамически, чтобы быстрее реагировать на ввод/вывод, он умеет отдавать квант времени другому потоку, если первый ждет чего-нибудь, на него завязан механизм RCU и механизм предотвращения инверсии приоритетов (random boosting в винде и priority inheritence в linux). В общем, мьютекс это довольно клево и интересно. Чтобы это понять, достаточно попробовать запилить что-нибудь нетривиальное на потоках/мьютексах/общей памяти и на сообщениях.
Мамут в каждом сообщении подразумевает масштабируемость, распределенность и тд. С мутексами всё в порядке до тех пор, пока не понадобится масштабируемость.
Именно это он имеет ввиду, когда дает ссылку на дерево супервизоров.
EL>Ну и вообще, сообщения vs локи это ложная дихотомия, ибо операции с мьютексом можно рассматривать как отправку сообщения другому потоку.
Да, все правильно. Дело не в сообщениях, а в том, кто обеспечивает корректность состояния. С мутексами у тебя этим занят каждый из потоков.
Сообщения это никакие не сообщения, а агенты. Просто у мамута такая терминология — каждое слово чтото значит, только он забывает сказать, какое слово в каком смысле употребляет. Каждый агент обеспечивает корректность своего состояния, и никто, кроме него, это состояние не видит.
EL>Во первых, я предложил реализовать какой-нибудь параллельный алгоритм (на erlang-е же можно их писать, да?), а не часть erlang-а. Слабо написать параллельный счетчик например, ну или CM-sketch? Мне не очевидно, что erlang может быть полезен для решения параллельных задач, с которыми мне приходилось сталкиваться в реальной жизни. Слабо верится что с его помощью можно даже простые статистические свойства потока сообщений приходящих на сервер оценить, я уже молчу о какой-нибудь более сложной обработке.
Реализовать можно, естественно
EL>Во вторых, твои любимые супервайзеры имеют смысл только в языке с теми же свойствами что и erlang, процесс упал, мы его рестартанули и все, процесс продолжил потреблять очередь. В языке с общей памятью таск может упасть не из-за того что лежит в очереди а из-за того что лежит в этой самой общей памяти. Принцип let it fail тут применять не принято. В общем, вижу это как продолжение слива, решил предложить то что никто не возьмется делать и то что в erlang-е уже есть.
Где ты увидел продолжение слива, известно только тебе.
Зачем нужны супервайзоры и прочее, я уже писал. Прикинь. В превом сообщении в этой теме. Потому что каждый первый, кто говорит, что ничего это ненужно на практике занимается (почти цитата) «ну пару catch'ей ручками расставим, не сложно» и прочими ручными реализациями «половины эрланга». В этой подветке
Здравствуйте, ELazin, Вы писали:
EL>Во первых, я предложил реализовать какой-нибудь параллельный алгоритм (на erlang-е же можно их писать, да?), а не часть erlang-а. Слабо написать параллельный счетчик например, ну или CM-sketch? Мне не очевидно, что erlang может быть полезен для решения параллельных задач, с которыми мне приходилось сталкиваться в реальной жизни. Слабо верится что с его помощью можно даже простые статистические свойства потока сообщений приходящих на сервер оценить, я уже молчу о какой-нибудь более сложной обработке.
Параллельные алгоритмы для мамута — табу. Скорее всего он тебе ответит "Ага, попался ! Снова — 'я умею создавать 100500 потоков эрланг не нужен' => неумеешьчитать"
EL>Во вторых, твои любимые супервайзеры имеют смысл только в языке с теми же свойствами что и erlang, процесс упал, мы его рестартанули и все, процесс продолжил потреблять очередь. В языке с общей памятью таск может упасть не из-за того что лежит в очереди а из-за того что лежит в этой самой общей памяти. Принцип let it fail тут применять не принято. В общем, вижу это как продолжение слива, решил предложить то что никто не возьмется делать и то что в erlang-е уже есть.
Дело в различных принципах декомпозиции систем. На эрланге скорее всего никогда не возникает "упадёт из-за того что лежит в этой самой общей памяти".
Собтвенно, это одна из причин, почему эрланг мало где применяется. Слишком много ограничений накладывает.
Re[28]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, Mamut, Вы писали:
M>Сколько бы потоков не создавалось, это все упирается в создание X штук неуправляемых потоков. Повторю еще раз: как тебе понадобится что-то чуть более сложное, ты загнешься.
Само собой. Просто в случае малого числа задач, управление этими системными потоками весьма тривиально (собственно просто каждая задача исполняется в своём системном потоке) и соответственно сложная система с кучей оверхеда, предназначенная для работы с тысячами одновременных задач, выглядит в этом случае неуместно.
_>>Т.е. в языке из коробки отсутствует инструмент для реализации подобного многопоточного кода и надо ставить стороннюю библиотеку. Правильно? ) M>
_>>Не, не, я не настаиваю на точно таком виде. Можно пользоваться любыми инструментами языка. Меня интересует всего лишь один простой вопрос: какой объём кода будет у реализации подобной (в смысле результата) многопоточной обработки данных на Эрланге.
M>такой же, если берётся сторонняя библиотека/модуль.
M>и короче, если у плюсов тоже отнять стороннюю библиотеку.
Так в C++ то как раз OpenMP из коробки. Т.е. ты всю эту темку утверждал как всё удобно и классно в Эрланге из коробки, а в C++ надо мучиться с установкой сторонних библиотек. А на данном примере мы увидели, что это Эрлангу надо ставить сторонние библиотеки для реализации элементарной многопоточности, в то время как в C++ данная функциональность как раз имеется из коробки.
M>>>- в случае с plists имеет гибкость: например, можно запустить обработку на другой ноде (которая может быть на другом компьютере) _>>Это уже не имеет отношения к написанию софта — это скорее вопрос к администраторам. ) M>Это напрямую имеет отношение к написанию софта. Никакой администратор не научит твой openmp находить ноды в сети и запускать код на этих нодах.
А причём тут мой код и такое? ) Распространением софта должны заниматься специлизированные инструменты, уже давно написанные и конфигурируемы админами. Если же ты говоришь про взаимодействие моего софта, при его выполнение на нескольких узлах, то это уже действительно моё дело и оно легко реализуется с помощью MPI (инструмент дополняющий OpenMP и SIMD, для полноценного распараллеливания на всех трёх возможных уровнях).
_>>Ну да, ну да, немного несложного кода... Кстати, а функция get_index где? ) Ты вообще понимаешь, что при таком раскладе она должна быть замыканием, содержащим сам список L? Т.е. ты будешь её каждый раз писать заново? ) M>Возьми структуру данных, в которой реализован доступ по индексу — и вперед
Я не про это. У тебя в get_index передаётся только элемент списка, но не сам список. Соответственно чтобы такой странный код работал, у тебя внутри get_index должна содержаться ссылка на этот конкретный список L.
_>>Ну и если в итоге посмотреть на данный код (для которого надо ещё дописать функции и поставить библиотечку) и на мой пример (собираемый стандартной поставкой компилятора), то где у нас в итоге получается закат солнца вручную в следствие слабой реализации многопоточности? ))) M>Действительно. Широкие выводы из умению развернуть цикл в параллельный fold/map.
А это я просто попытался взять пример с тебя) Эрланг же действительно неплох в своей узкой нише. Но ты на основе этого сделал вывод что он хорош вообще в любом многопоточном программирование. Вот и я делаю аналогичные выводы на основе этого примера: Эрланг вообще ничего не может, т.к. тривиальный пример выглядит на нём на порядок страшнее, чем в даже древнем Фортране. Нравится подобный стиль формирования выводов?
M>Именно потому ты так упорно цепляешься строго и исключительно за этот пример, а остальное называешь демагогией.
Я думаю ты знаешь, что в математике наличие даже маленького одиночного контрпримера, полностью опровергают всю предложенную теорию. Так вот реализация данной задачки — это контрпример ко всем твоим размышлениям в первом сообщение темки.
Re[7]: Эрланг и все-все-все (на самом деле, не совсем)
EL>>В общем, мьютекс это довольно клево и интересно. Чтобы это понять, достаточно попробовать запилить что-нибудь нетривиальное на потоках/мьютексах/общей памяти и на сообщениях. F>а что есть подобного нетривиального?
Я там выше предлагал CM sketch или даже простой параллельный счетчик. Тривиальный параллельный алгоритм, это например embarrassingly parallel задачи, Монте-Карло например, ну или data parallel задачи, это когда данные, с которыми работает процесс, принадлежат этому потоку и никто их больше не трогает. Нетривиальный параллельный алгоритм, это когда данные, к сожалению, не могут принадлежать одному потоку и при этом данные нужно как-нибудь обновлять.
Re[29]: Эрланг и все-все-все (на самом деле, не совсем)
M>>Сколько бы потоков не создавалось, это все упирается в создание X штук неуправляемых потоков. Повторю еще раз: как тебе понадобится что-то чуть более сложное, ты загнешься.
_>Само собой. Просто в случае малого числа задач, управление этими системными потоками весьма тривиально (собственно просто каждая задача исполняется в своём системном потоке) и соответственно сложная система с кучей оверхеда, предназначенная для работы с тысячами одновременных задач, выглядит в этом случае неуместно.
1. Что там за оверхед, известно только тебе
2. Система, которая позволяет единообразно работать с потоками/процессами — это плохо, ок, я тебя понял
M>>>>- в случае с plists имеет гибкость: например, можно запустить обработку на другой ноде (которая может быть на другом компьютере) _>>>Это уже не имеет отношения к написанию софта — это скорее вопрос к администраторам. ) M>>Это напрямую имеет отношение к написанию софта. Никакой администратор не научит твой openmp находить ноды в сети и запускать код на этих нодах.
_>А причём тут мой код и такое? ) Распространением софта должны заниматься специлизированные инструменты, уже давно написанные и конфигурируемы админами.
Боже. Ты даже не удосужился попытаться понять, что я говорю /o\ Главное поскорее настрочить ответ!!!
_>Если же ты говоришь про взаимодействие моего софта, при его выполнение на нескольких узлах, то это уже действительно моё дело и оно легко реализуется с помощью MPI (инструмент дополняющий OpenMP и SIMD, для полноценного распараллеливания на всех трёх возможных уровнях).
«Легко», я так предполагаю.
_>>>Ну да, ну да, немного несложного кода... Кстати, а функция get_index где? ) Ты вообще понимаешь, что при таком раскладе она должна быть замыканием, содержащим сам список L? Т.е. ты будешь её каждый раз писать заново? ) M>>Возьми структуру данных, в которой реализован доступ по индексу — и вперед
_>Я не про это. У тебя в get_index передаётся только элемент списка, но не сам список. Соответственно чтобы такой странный код работал, у тебя внутри get_index должна содержаться ссылка на этот конкретный список L.
Действительно, раз нет аргументов, придерись к отдельным кускам кода. Хотя я прямым текстом написал, что в Эрланге не получится сделать точно так же, потому что нет такой же структуры данных. И написал что? Ах, да «предположим, что у нас есть функция get_index». Читать? Понимать написанное? Зачем?!
_>>>Ну и если в итоге посмотреть на данный код (для которого надо ещё дописать функции и поставить библиотечку) и на мой пример (собираемый стандартной поставкой компилятора), то где у нас в итоге получается закат солнца вручную в следствие слабой реализации многопоточности? ))) M>>Действительно. Широкие выводы из умению развернуть цикл в параллельный fold/map.
_>А это я просто попытался взять пример с тебя) Эрланг же действительно неплох в своей узкой нише. Но ты на основе этого сделал вывод что он хорош вообще в любом многопоточном программирование.
Мне еще попрекают, что я обвиняю других в том, что они читать не умеют. А что поделать, если действительно не умеют читать. Вот именно из разряда: вижу текст, пишу ответ по каким-то своим фантазиям, с текстом несвязанным.
I>Мамут в каждом сообщении подразумевает масштабируемость, распределенность и тд. С мутексами всё в порядке до тех пор, пока не понадобится масштабируемость.
Легкость переноса процессов на другие машины вовсе не гарантирует масштабируемость.
Re[7]: Эрланг и все-все-все (на самом деле, не совсем)
I>Мамут в каждом сообщении подразумевает масштабируемость, распределенность и тд. С мутексами всё в порядке до тех пор, пока не понадобится масштабируемость. I>Именно это он имеет ввиду, когда дает ссылку на дерево супервизоров.
Когда я даю ссылку на дерево супервизоров, я имею в виду управление потоками/процессами/задачами в первую очередь.
Заметно, как ты понимаешь, что я пишу, несмотря на максмально простой стиль изложения.
Здравствуйте, Mamut, Вы писали:
M>1. Что там за оверхед, известно только тебе
От ненужного кода. Планировщик то никуда не девается, хотя пользы от него тут нет. И т.п.
M>2. Система, которая позволяет единообразно работать с потоками/процессами — это плохо, ок, я тебя понял
В том то и дело, что не позволяет — мы это уже увидели на примере. )
_>>Если же ты говоришь про взаимодействие моего софта, при его выполнение на нескольких узлах, то это уже действительно моё дело и оно легко реализуется с помощью MPI (инструмент дополняющий OpenMP и SIMD, для полноценного распараллеливания на всех трёх возможных уровнях). M>«Легко», я так предполагаю.
Конечно. Ведь на этой связке (ну плюс ещё CUDA для гетерогенных систем) работает большинство больших вычислительных комплексов.
_>>Я не про это. У тебя в get_index передаётся только элемент списка, но не сам список. Соответственно чтобы такой странный код работал, у тебя внутри get_index должна содержаться ссылка на этот конкретный список L. M>Действительно, раз нет аргументов, придерись к отдельным кускам кода. Хотя я прямым текстом написал, что в Эрланге не получится сделать точно так же, потому что нет такой же структуры данных. И написал что? Ах, да «предположим, что у нас есть функция get_index». Читать? Понимать написанное? Зачем?!
Ты похоже плохо воспринимаешь текст. ) Я же вроде по русски пишу, что претензия не в проблемах с массивами в Эрланге, а в том, что у тебя тут функции get_index передаётся исключительно элемент X, на основе которого она как-то вычисляет его индекс в списке L (не известном ей). Поясни работу эту функции (предполагая, что допустим структура работающая с индексами у тебя есть). Иначе этот твой код не засчитывается за реализацию.
_>>А это я просто попытался взять пример с тебя) Эрланг же действительно неплох в своей узкой нише. Но ты на основе этого сделал вывод что он хорош вообще в любом многопоточном программирование. M>Мне еще попрекают, что я обвиняю других в том, что они читать не умеют. А что поделать, если действительно не умеют читать. Вот именно из разряда: вижу текст, пишу ответ по каким-то своим фантазиям, с текстом несвязанным.
Т.е. ты согласен, что Эрланг полезен (и то если скорость разработки важнее расходов на железо) только для узкой ниши высоконагруженных серверов? )
Re[8]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, ELazin, Вы писали:
I>>Мамут в каждом сообщении подразумевает масштабируемость, распределенность и тд. С мутексами всё в порядке до тех пор, пока не понадобится масштабируемость.
EL>Легкость переноса процессов на другие машины вовсе не гарантирует масштабируемость.
Да, мамут все время говорит только про ту масштабируемость, которая решается переносом на другую машину
Re[9]: Эрланг и все-все-все (на самом деле, не совсем)
I>>>Мамут в каждом сообщении подразумевает масштабируемость, распределенность и тд. С мутексами всё в порядке до тех пор, пока не понадобится масштабируемость. EL>>Легкость переноса процессов на другие машины вовсе не гарантирует масштабируемость. I>Да, мамут все время говорит только про ту масштабируемость, которая решается переносом на другую машину
Да уж. УРовень твоего понимания печатного текста просто поражает.
Здравствуйте, Mamut, Вы писали:
I>>Мамут в каждом сообщении подразумевает масштабируемость, распределенность и тд. С мутексами всё в порядке до тех пор, пока не понадобится масштабируемость. I>>Именно это он имеет ввиду, когда дает ссылку на дерево супервизоров.
M>Когда я даю ссылку на дерево супервизоров, я имею в виду управление потоками/процессами/задачами в первую очередь.
И когда тебе напоминают про параллельные задачи, ты тут же начинаешь стенать "снова 100500 потоков".
Параллельные задачи это целиком про управление потоками-процессами-задачами.
Скажем, системно-зависимый функционал, он тоже про такое управление. Но внезапно, эрланг уже не может в силу ряда причин — например потому, что в ОС целый вагон блокирующих вызовов из за того, что куча объектов прибито гвоздями к физическому потоку.
Потому правильно говорить например про масштабирование, а не абстрактное управление.
M>Заметно, как ты понимаешь, что я пишу, несмотря на максмально простой стиль изложения.
Я и говорю — ты объясняешь сам себе, потому всё кажется просто.
Re[31]: Эрланг и все-все-все (на самом деле, не совсем)
M>>1. Что там за оверхед, известно только тебе _>От ненужного кода. Планировщик то никуда не девается, хотя пользы от него тут нет. И т.п.
Угу. Сферовакуумный оферхед из твоих фантазий. mmkay.
M>>2. Система, которая позволяет единообразно работать с потоками/процессами — это плохо, ок, я тебя понял _>В том то и дело, что не позволяет — мы это уже увидели на примере. )
Там решение строго на основе единообразных инструментов, если что. А не в виде «расширения к языку с равным уровнем поддержки в разных компиляторах».
_>>>Если же ты говоришь про взаимодействие моего софта, при его выполнение на нескольких узлах, то это уже действительно моё дело и оно легко реализуется с помощью MPI (инструмент дополняющий OpenMP и SIMD, для полноценного распараллеливания на всех трёх возможных уровнях). M>>«Легко», я так предполагаю.
_>Конечно. Ведь на этой связке (ну плюс ещё CUDA для гетерогенных систем) работает большинство больших вычислительных комплексов.
Что делать, если у меня не «вычислительный комплекс»? Что, если я хочу просто запустить десяток потоков/процессов? Ах да, я помню. «проще несколько catch'ей ручками расставить», ага
_>Ты похоже плохо воспринимаешь текст. ) Я же вроде по русски пишу, что претензия не в проблемах с массивами в Эрланге, а в том, что у тебя тут функции get_index передаётся исключительно элемент X, на основе которого она как-то вычисляет его индекс в списке L (не известном ей). Поясни работу эту функции (предполагая, что допустим структура работающая с индексами у тебя есть). Иначе этот твой код не засчитывается за реализацию.
/o\ Просто без комментариев. У него, видите ли, претензия к функции, про котороую сразу написано, что она гипотетическая.
_>>>А это я просто попытался взять пример с тебя) Эрланг же действительно неплох в своей узкой нише. Но ты на основе этого сделал вывод что он хорош вообще в любом многопоточном программирование. M>>Мне еще попрекают, что я обвиняю других в том, что они читать не умеют. А что поделать, если действительно не умеют читать. Вот именно из разряда: вижу текст, пишу ответ по каким-то своим фантазиям, с текстом несвязанным.
_>Т.е. ты согласен, что Эрланг полезен (и то если скорость разработки важнее расходов на железо) только для узкой ниши высоконагруженных серверов? )
I>>>Мамут в каждом сообщении подразумевает масштабируемость, распределенность и тд. С мутексами всё в порядке до тех пор, пока не понадобится масштабируемость. I>>>Именно это он имеет ввиду, когда дает ссылку на дерево супервизоров.
M>>Когда я даю ссылку на дерево супервизоров, я имею в виду управление потоками/процессами/задачами в первую очередь.
I>И когда тебе напоминают про параллельные задачи, ты тут же начинаешь стенать "снова 100500 потоков". I>Параллельные задачи это целиком про управление потоками-процессами-задачами.
Покажи мне, где у alex_public в его примере управление потоками.
I>Скажем, системно-зависимый функционал, он тоже про такое управление. Но внезапно, эрланг уже не может в силу ряда причин — например потому, что в ОС целый вагон блокирующих вызовов из за того, что куча объектов прибито гвоздями к физическому потоку.
Пока что все, что большинство, включая тебя, смогло сказать про управление — это «зачем оно нужно», «не, невозможно», «зачем убивать потоки» и прочее типа «на мьютексах все можно сделать, это как сообщшения»
Хотя, казалось бы, даже без привязки к Эрлангу все было написано в первом же сообщении. Но читать? Думать над написанным? ЗАЧЕМ?!
I>Потому правильно говорить например про масштабирование, а не абстрактное управление.
M>>Заметно, как ты понимаешь, что я пишу, несмотря на максмально простой стиль изложения. I>Я и говорю — ты объясняешь сам себе, потому всё кажется просто.
Там действительно все просто. Просто ты не делаешь даже попыток понять, что там написано. Плюс зашоренность.
Здравствуйте, Mamut, Вы писали:
M>Что делать, если у меня не «вычислительный комплекс»? Что, если я хочу просто запустить десяток потоков/процессов? Ах да, я помню. «проще несколько catch'ей ручками расставить», ага
Ну давай проверим, чего там. Придумаем простецкий воркфлоу, что бы была польза от эти десятка потоков-процессов, ну скажем, конвертацию из одного формата в другой. Вот смотри — надо наклепать плагинчик для офиса какого, что бы работал у вындоусе ин-процес или на андройде и тд. Ну и основной контекст это оффлайн, юзеры просят, аж пищат.
Для андройда кстати очень актуальная проблема — там очень сложно всё с потоками, Эрланг ажно просится.
Плагин простой — встраивается в UI и показывает прогресс этих самых задач.
Валяй, покажи чем ты тут науправляешь и сколько десятков лет или столетий у тебя уйдет на то, что бы всунуть Эрланг в классические десктоп и мобайл приложения.
Код писать не нужно, просто объясни внятно, без идиотии в духе "вот ссылка на дерево супервизоров"
Re[10]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, Mamut, Вы писали:
I>>И когда тебе напоминают про параллельные задачи, ты тут же начинаешь стенать "снова 100500 потоков". I>>Параллельные задачи это целиком про управление потоками-процессами-задачами.
M>Покажи мне, где у alex_public в его примере управление потоками.
Запустить, выбрать все физические ядра, выполнить, собрать результаты, остановить.
I>>Скажем, системно-зависимый функционал, он тоже про такое управление. Но внезапно, эрланг уже не может в силу ряда причин — например потому, что в ОС целый вагон блокирующих вызовов из за того, что куча объектов прибито гвоздями к физическому потоку.
M>Пока что все, что большинство, включая тебя, смогло сказать про управление — это «зачем оно нужно», «не, невозможно», «зачем убивать потоки» и прочее типа «на мьютексах все можно сделать, это как сообщшения»
Ты прямо про себя пишешь, с небольшой разницей, если поменять мутексы на супервайзеры. Для чего нужно управление такое, тебе еще предстоит открыть.
M>Хотя, казалось бы, даже без привязки к Эрлангу все было написано в первом же сообщении. Но читать? Думать над написанным? ЗАЧЕМ?!
Над всяким говном никто в своём уме думать не будет.
M>>>Заметно, как ты понимаешь, что я пишу, несмотря на максмально простой стиль изложения. I>>Я и говорю — ты объясняешь сам себе, потому всё кажется просто.
M>Там действительно все просто. Просто ты не делаешь даже попыток понять, что там написано. Плюс зашоренность.
Я уже давно замечаю, когда основной аргумент "там всё просто", то всегда кругозор с игольное ушко.
Скажу страшное — простота меряется не в количестве строчек текста и даже не в строчках на Эрланге.
Re[7]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, BulatZiganshin, Вы писали:
BZ>я в своё время недоумённо спрашивал, откуда у вас, сишников, проблемы многопоточности — на хаскеле их у меня не было. при message passing approach ошибки синхронизации просто отсутствуют. на самом деле в реальной программе у меня есть несколько раздляемых ресурсов, но их так мало, что контролировать несложно. скажем, обращение к выходному файлу я просто обернул в мьютекс и потому разные потоки в принципе не могут его делать одновременно
Элементарно, Ватсон!
Первый вариант программы скорее всего не содержит ошибок синхронизации: инварианты учтены, шареные данные синхронизированы правильно (места возможных гонок и дедлоков просмотрены), а потом, в процессе развития программы (или в процессе багфиксов) допишет что-нибудь вот такое:
private volatile m_sumThingEnabled
public bool IsSumThingEnabled
{
get{ return m_sumThingEnabled;}
set
{
m_sumThingEnabled = value;
OnChangedEnabledSomthing();
}
}
не учтя при этом, что свойство из другого потока может быть изменено, и всё — привет отладка логированием.
Ясен пень, что этот пример взят с потолка, но суть проблемы он в принципе демонстрирует.
Всё сказанное выше — личное мнение, если не указано обратное.
Re[33]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, Ikemefula, Вы писали:
I>Ну давай проверим, чего там. Придумаем простецкий воркфлоу, что бы была польза от эти десятка потоков-процессов, ну скажем, конвертацию из одного формата в другой.
Зачем ковертацию? Это опять же получится числодробилка, где несколько параллельных процессов порождаются, обслуживают некоторые вычислительные задачи и дохнут безо всякого управления. Интереснее было бы, если бы каждый процесс получал некоторые данные извне (можно эмулировать через ГСЧ для простоты), анализировал их и в зависимости от результата решал, что ему делать дальше:
— завершиться штатно
— сдохнуть аварийно
— запустить N дочерних процессов и опрашивать их при дальнейшем анализе
— притормозить на время и известить об этом родителя
— грохнуть принудительно всех детей
— и т.п.
Я ж так понимаю Мамут в своих спичах делает упор на легкость именно управления процессами, а не тупо их создания в количестве "дофига штук". А легкость управления лучше всего проверяется его многообразием.
