S>Ну конечно же есть состояние. Чем, по-вашему, отличается поток "до" wait_notify(), "во время" wait_notify(), и "после" wait_notify()? Вот вы говорите о выполнении инструкций — значит, есть понятияме instruction pointer. Кроме того, у вас там идут вызовы — значит, есть stack. Эти понятия — и есть состояние, без которого никакого "потока" нет.
Думаю состоянием самого потока(включая его локальные переменные), в контексте проблемы синхронизации потоков, можно пренебречь, т.к. оно не нуждается в синхронизации. И насколько я понимаю в чистом ФП так-же есть последовательность вычисления(порядок вызова/раскрытия функций), получается и там есть состояние? CAB>>Допустим потоки там не нужны. Но меня больше интересует
вопрос: как это распаралеллить(чтоб ускорить вычисление)? S>В случае чистой математики — частично-рекурсивные функции отвечают на ваш вопрос.
Как бы вы распараллелили конкретно эту задачу? S>Вот у вас есть определения функций, есть граф зависимостей. В каждый момент у вас есть функции, у которых определены все входы => значит, можно выполнить вычисление этих функций. Если таких функций больше, чем одна, то можно запустить вычисления параллельно в таком же количестве аппаратных потоков. После вычисления становятся "доступными" другие функции, их можно вычислять дальше.... Dataflow programming? Этот подход так-же не устойчив к дедлокам(если его конечно не кастрировать до строгого дерева
). S>2. Автоматических конвертеров "активных" алгоритмов в "реактивные" — типа await/async в новом шарпе
Интересно. Опишите пожалуйста в нескольких словах, как это работает.
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
CAB>>100 не надо(это не имеет смыла, программа не будет работать быстрее). Если например в системе имеется 4 процессора(ядра), то достаточно 4-х системных потоков(хотя, если это нужно, можно и больше чтобы использовать вытесняющую многозадачность). N>Не вижу связи между ядрами и потоками. (в данном контексте)
Если потоков будет больше чем процессоров, то какие то из потоков будут делить один процессор, т.е. скорость выполнения программы не возрастёт CAB>>Новые вызовы будут ожидать появления в пуле свободных потоков, т.е. ожидать когда какая ни будь работающая функция завершится или остановится на wait. N>ок, а если функция не завершится или не остановится, то это приведет к зависанию?
Да.
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
CAB>>Тогда веть придётся синхронизировать не только доступ ко всему массиву, но и к каждому элементу по отдельности. M>Ну, в Erlang'е для новых версий так и собираются делать, емнип. Но сейчас презентацию не найду.
Разве это не потребует гораздо больших затрат на синхронизацию?
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Здравствуйте, C.A.B, Вы писали:
CAB>Если потоков будет больше чем процессоров, то какие то из потоков будут делить один процессор, т.е. скорость выполнения программы не возрастёт
Можно сказать, что я почти об этом же.
Зачем вам вызов каждой функции в отдельном потоке?
CAB>Да.
Не лучше ли тогда доверить пользователю управление этими вещами?
CAB>>>Тогда веть придётся синхронизировать не только доступ ко всему массиву, но и к каждому элементу по отдельности. M>>Ну, в Erlang'е для новых версий так и собираются делать, емнип. Но сейчас презентацию не найду. CAB>Разве это не потребует гораздо больших затрат на синхронизацию?
Здравствуйте, C.A.B, Вы писали: CAB>Думаю состоянием самого потока(включая его локальные переменные), в контексте проблемы синхронизации потоков, можно пренебречь, т.к. оно не нуждается в синхронизации.
Ну конечно же им нельзя пренебречь. И вы это только что сами же наглядно показали, продемонстрировав deadlock на ожиданиях, несмотря на отсутствие состояния "самого потока".
И насколько я понимаю в чистом ФП так-же есть последовательность вычисления(порядок вызова/раскрытия функций), получается и там есть состояние?
Частичный порядок — есть. Можно сделать его полным, явно введя состояние. Но это — фактически, ручная эмуляция императива.
CAB>Как бы вы распараллелили конкретно эту задачу?
Конкретно какую? С бегущим средним? Вообще бы параллелить не стал. Там узкое место — доступ к памяти, а не CPU. CAB>Dataflow programming? Этот подход так-же не устойчив к дедлокам(если его конечно не кастрировать до строгого дерева
). S>>2. Автоматических конвертеров "активных" алгоритмов в "реактивные" — типа await/async в новом шарпе CAB>Интересно. Опишите пожалуйста в нескольких словах, как это работает.
В несколько слов уложится только "погуглите".
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Mamut, Вы писали:
M>Видимо, зависит от реализации
И опять я рекомендую обратиться к опыту СУБД — как там ухитряются обходиться конечным количеством объектов блокировки при самых разных масштабах изменений, вносимых в транзакции. Краткий ответ — многоурровневая блокировка и эскалация.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
N>Зачем вам вызов каждой функции в отдельном потоке?
Для упрощения модели: вместо "есть функции которые вызываются в отдельном потоке, и есть которые не" сделать "все функции вызываются в отдельном потоке", а дальше компилятор и рантайм сами разберутся какую функцию вызывать в отдельном потоке а какую нет. N>Не лучше ли тогда доверить пользователю управление этими вещами?
Я бы хотел избавить пользователя от заботы об этих вещах.
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
CAB>>Думаю состоянием самого потока(включая его локальные переменные), в контексте проблемы синхронизации потоков, можно пренебречь, т.к. оно не нуждается в синхронизации. S>Ну конечно же им нельзя пренебречь.
Почему? Если мы предположим что поток не имеет состояния, к каким ошибкам это может привести? S>И вы это только что сами же наглядно показали, продемонстрировав deadlock на ожиданиях, несмотря на отсутствие состояния "самого потока".
Тот пример об зависимости между потоками, если бы они были не зависимы(не содержали бы wait), то и дедлока не было бы. S>И насколько я понимаю в чистом ФП так-же есть последовательность вычисления(порядок вызова/раскрытия функций), получается и там есть состояние? S>Частичный порядок — есть. Можно сделать его полным, явно введя состояние. Но это — фактически, ручная эмуляция императива.
ИМХО, вы запутались, и пытаетесь "натянуть" термин "состояние" на вещи которые обычно в программировании таковым не считаются(на порядок выполнения, в частности).
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Здравствуйте, C.A.B, Вы писали:
CAB>Почему? Если мы предположим что поток не имеет состояния, к каким ошибкам это может привести?
Что вы называете "состоянием"? В строгом определении, у потока всегда есть состояние — я вам это уже объяснил.
Если вы имеете в виду то, что у потока нет разделяемого состояния — тогда да, это и есть решение проблемы дедлоков, т.к. Тогда блокировки вообще не нужны. S>>И вы это только что сами же наглядно показали, продемонстрировав deadlock на ожиданиях, несмотря на отсутствие состояния "самого потока". CAB>Тот пример об зависимости между потоками, если бы они были не зависимы(не содержали бы wait), то и дедлока не было бы. а кто вам обещал дедлок на независимых потоках? Поймите, что там, где блокировки — там и взаимоблокировки. S>>И насколько я понимаю в чистом ФП так-же есть последовательность вычисления(порядок вызова/раскрытия функций), получается и там есть состояние? S>>Частичный порядок — есть. Можно сделать его полным, явно введя состояние. Но это — фактически, ручная эмуляция императива. CAB>ИМХО, вы запутались, и пытаетесь "натянуть" термин "состояние" на вещи которые обычно в программировании таковым не считаются(на порядок выполнения, в частности).
Я не знаю, что вы называете "обычно", и почему решили, что запутался я, а не вы. Речь о базовых понятиях: что такое императивное программирование, чем оно отличается от декларативного в целом и функционального в частности. Порядок выполнения сам по себе состоянием не является, но без наличия изменяемого состояния о порядке выполнения не имеет смысла.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
S>Если вы имеете в виду то, что у потока нет разделяемого состояния — тогда да, это и есть решение проблемы дедлоков, т.к. Тогда блокировки вообще не нужны.
Да. CAB>>Тот пример об зависимости между потоками, если бы они были не зависимы(не содержали бы wait), то и дедлока не было бы. S> а кто вам обещал дедлок на независимых потоках? Поймите, что там, где блокировки — там и взаимоблокировки.
Вот и я о том-же, проблема в зависимостях потоков а не в их состоянии. S> Я не знаю, что вы называете "обычно", и почему решили, что запутался я, а не вы. Речь о базовых понятиях: что такое императивное программирование, чем оно отличается от декларативного в целом и функционального в частности.
Может быть и я, запутался. S> Порядок выполнения сам по себе состоянием не является, но без наличия изменяемого состояния о порядке выполнения не имеет смысла. Функциональщики говорят.
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Здравствуйте, C.A.B, Вы писали:
CAB>Dataflow programming? Этот подход так-же не устойчив к дедлокам(если его конечно не кастрировать до строгого дерева
Не обязательно дерева, достаточно ациклического графа.
И это необязательно dataflow, функциональный стиль программирования также порождает ациклический граф. Более того, любой стиль программирования в конечном итоге порождает ациклический граф выполнения функций. А дедлоки возникают на стадии порождения графа. Используя функциональный стиль, дедлок получить практически невозможно. Dataflow — надо специально постараться. А императивный — сплошь и рядом.
Здравствуйте, C.A.B, Вы писали:
S>> а кто вам обещал дедлок на независимых потоках? Поймите, что там, где блокировки — там и взаимоблокировки. CAB>Вот и я о том-же, проблема в зависимостях потоков а не в их состоянии.
Зависимости возникают исключительно за счёт разделяемого состояния.
S>> Порядок выполнения сам по себе состоянием не является, но без наличия изменяемого состояния о порядке выполнения не имеет смысла. CAB> Функциональщики говорят.
И что конкретно по ссылке вам непонятно? Там ровно то же, что объясняю вам я:
Функциональное программирование предполагает обходиться вычислением результатов функций от исходных данных и результатов других функций, и не предполагает явного хранения состояния программы.
В отличие от императивного стиля, описывающего шаги, ведущие к достижению цели, функциональный стиль описывает математические отношения между данными и целью
Поскольку отсутствие побочных эффектов гарантировано, в любом вызове функции всегда допустимо параллельное вычисление двух различных параметров — порядок их вычисления не может оказать влияния на результат вызова
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
S>Зависимости возникают исключительно за счёт разделяемого состояния.
Ok, как быть с лайфлоками? CAB>> Функциональщики говорят. S>И что конкретно по ссылке вам непонятно? Там ровно то же, что объясняю вам я:
Всё понятно. Это я к тому что "обычно" называют состоянием программы. Но не суть.
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Здравствуйте, C.A.B, Вы писали:
S>>Зависимости возникают исключительно за счёт разделяемого состояния. CAB>Ok, как быть с лайфлоками?
Я не понимаю ваш вопрос. Вы понимаете, что вообще само понятие "лока" основано на состоянии, и на разделяемых данных?
Все "локи" изоморфны ровно одному примитиву синхронизации (любому). Например, возьмём примитив "мьютекс".
У мьютекса есть состояние: он либо захвачен, тогда в состояние входит ID потока, захватившего мьютекс, либо свободен. У потока есть состояние — с точки зрения шедулера, это состояние либо "может исполняться", либо "стоит в ожидании мьютекса".
Разделяемое это состояние потому, что два (и более) потоков оперируют над одним и тем же экземпляром мьютекса.
Что именно вам тут непонятно?
CAB>Всё понятно. Это я к тому что "обычно" называют состоянием программы. Но не суть.
Ну вот то, что там написано — ровно то же, о чём пишу вам я. А вы мне отвечаете так, как будто есть какие-то разночтения между википедией и моим пониманием.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
S>>>Зависимости возникают исключительно за счёт разделяемого состояния. CAB>>Ok, как быть с лайфлоками? S>Я не понимаю ваш вопрос. Вы понимаете, что вообще само понятие "лока" основано на состоянии, и на разделяемых данных?
Например случай с кольцевой пересылкой сообщений
. Там нет ни разделяемого состояния ни разделяемых данных. Или есть?
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Здравствуйте, C.A.B, Вы писали:
S>>>>Зависимости возникают исключительно за счёт разделяемого состояния. CAB>>>Ok, как быть с лайфлоками? S>>Я не понимаю ваш вопрос. Вы понимаете, что вообще само понятие "лока" основано на состоянии, и на разделяемых данных? CAB>Например случай с кольцевой пересылкой сообщений
. Там нет ни разделяемого состояния ни разделяемых данных. Или есть?
По прежнему не понимаю вопрос. Предложенная схема с пинг-понгом, по большому счёту, изоморфна бесконечному циклу в императивном языке программирования. Пока что никаких средств предотвращения бесконечных циклов в императивных языках нету, и народ как-то не очень переживает по этому поводу.
Более того, можно породить такой пример и на одном потоке: пусть он посылает сообщение А сам себе. Всё время. Ну и что?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
