Здравствуйте, BulatZiganshin, Вы писали:

_>>Сопрограммы для реализации конечного автомата? ) Это что-то новенькое... ))) Если мне надо реализовать конечный автомат (именно его, а не какое-то параллельное исполнение), то я уже показал с помощью какого инструмента я буду его реализовывать. И вряд ли у тебя получится удобнее. )
BZ>когда в этот конечный автомат входит текущая позиция в стёке вызовов, вряд ли получится удобней чем с сопрограммами. преимущество сопрограмм — в том что код формально линейный, запросили данные — ту же получили ответ. не знаю какой ты инструмент имеешь в виду, но удобней resp = await ask() вряд ли будет

Ты опять же говоришь про конечный автомат написанный ради обработки кривого распараллеливания. А не ради самой предметной задачи, где конечный автомат будет и даже в полностью однопоточном случае, скажем для реализации некого протокола, формата и т.п... И для этих целей я соответственно возьму данный http://www.boost.org/doc/libs/1_59_0/libs/msm/doc/HTML/ch03s04.html#d0e1462 инструмент. Ну а что касается реализации многопоточности, то я стараюсь её писать так, чтобы там конечные автоматы (не предметные) не возникали вовсе.

Ну и да, код удобнее resp = await ask() очевидно есть. Это resp = ask().

LP>Чем это отличается это от того, что я написал? И с чего ты взял, что в эрланге все происходит именно так? Вон Мамут, который в отличие от тебя писал на эрланге, ничего подобного не приводит.

Взял он с того, что он, в отличие от тебя, знает, о чем говорит. И что я не приводил? Из двух строчек моего кода ты сделал далеко идущие выводы о том, что где когда и как переключается?

1. В Эрланге именно зеленые потоки, а не корутины, что бы ты там себе не нафантазировал. В Эрланге они называются процессами.
2. Процессы управляются планировщиками задач (по умолчанию — по одному на каждое ядро, но это настраиваемо)
3. Каждому процессу выделяется X редукций, где редукция — это посылка сообщения, вызов функции и т.п. После каждого сообщения вызова функции X уменьшается. Когда он достигает 0, процесс перемещается в конец очереди процессов, ожидающих обработку. Количество редукций тоже настраиваемо
4. Все переключения делаются прозрачно для самой программы. Стоимость переключения — какой-то незаметный никому мизер, в районе μs
5. Процесс, ожидающий получение сообщения вообще не потребляет CPU, потому что какой-либо код в нем выполнится только после того, как он получит сообщение
6. Переключение на другой процесс (а в вырожденных случаях — перенос процесса на другое ядро CPU) может произойти в любой момент практически любой точки кода, и произойдет незаметно для программы.

Здравствуйте, LaPerouse, Вы писали:

LP>Мда... Собственно, на это можно прекращать дискуссию, поскольку ты вообще не представляешь себе предмет обсуждения.
LP>Ключевые тезисы: иерархический конечный автомат, уменьшение количества состояний автомата за счет автоматического запоминания текущей позиции в стеке

Конечно не представляю. ))) Я же не расставляю конечные автоматы по всему коду и по любому поводу.

Вот скажем тот последний пример из первого сообщения реализуется на акторах в пару строк очевидного кода. Но мы вместо этого накрутим страшный конечный автомат на полстраницы и потом побежим на форум рассказывать про плохие акторы, которые приводят к такому дикому коду. )))

Здравствуйте, alex_public, Вы писали:

_>Здравствуйте, LaPerouse, Вы писали:

LP>>Мда... Собственно, на это можно прекращать дискуссию, поскольку ты вообще не представляешь себе предмет обсуждения.
LP>>Ключевые тезисы: иерархический конечный автомат, уменьшение количества состояний автомата за счет автоматического запоминания текущей позиции в стеке

_>Конечно не представляю. ))) Я же не расставляю конечные автоматы по всему коду и по любому поводу.

Я тебе верю. Ты похоже вообще слабо представляешь, что такое конечный автомат.

_>Вот скажем тот последний пример из первого сообщения реализуется на акторах в пару строк очевидного кода. Но мы вместо этого накрутим страшный конечный автомат на полстраницы и потом побежим на форум рассказывать про плохие акторы, которые приводят к такому дикому коду. )))

Давай, жду код.

Здравствуйте, Mamut, Вы писали:


LP>>Чем это отличается это от того, что я написал? И с чего ты взял, что в эрланге все происходит именно так? Вон Мамут, который в отличие от тебя писал на эрланге, ничего подобного не приводит.

M>Взял он с того, что он, в отличие от тебя, знает, о чем говорит. И что я не приводил? Из двух строчек моего кода ты сделал далеко идущие выводы о том, что где когда и как переключается?

Понимаешь, Булат буквально в первом или втором посту ответил на простой вопрос про coroutines в эрланге. То, что я не смог вытянуть у тебя за два дня общения. Значит, либо Булат фантазер (как я подумал сначала и похоже ошибся), либо уровень владения тобой предметом (эрланг) оставляет желать лучшего.

Здравствуйте, LaPerouse, Вы писали:

LP>Значит, либо Булат фантазер

ты бы хоть на мой профиль поглядел

LP>либо уровень владения тобой предметом (эрланг) оставляет желать лучшего.

мне неудобно говорить за мамута, но возможно он просто поленился повторять то, что мы уже 386 раз здесь обсуждали. в разрезе и эрланга, и хаскеля, и акторов, и бустовских библиотек. но теперь он подробно описал модель, по которой green threads реализовывается во всех языках, и в clr/jvm если соберутся — сделают также. других вариантов нет

Здравствуйте, alex_public, Вы писали:

_>Кстати, в C# с async/await вообще надо настороже быть. Потому как описываемое в данной темке поведение (с исполнением продолжения в изначальном потоке) там наблюдается только при условие (при дефолтных настройках), что изначальный поток — это тот самый главный GUI поток.

Вот тут поправлю. Используется контекст синхронизации текущего потока (контекст по умолчанию запускает код ч/з пул потоков, это да). Любой из фреймворков (wf, wf, winforms, asp.net etc) может подсунуть свою синхронизацию sync context. Код может быть запущен в родительском потоке, в общем пуле, в отдельном потоке или вообще на другой ноде (как в orleans), всё зависит от реализации.


2all

Разумеется, это не значит, что на голый await стоит натягивать акторы. Тут уже писали выше кучу раз про "любая достаточно сложная распределённая программа содержит заново написанную, неспецифицированную, глючную и медленную реализацию половины языка Erlang". Так вот, await сам по себе — это не та половина Нужно что-то похожее — вэлкам в эрланг/скалу/orleans со всеми их плюсами и минусами. Не хочется — вам оно точно нужно?

Здравствуйте, alex_public, Вы писали:

_>>>Сопрограммы для реализации конечного автомата? ) Это что-то новенькое... ))) Если мне надо реализовать конечный автомат (именно его, а не какое-то параллельное исполнение), то я уже показал с помощью какого инструмента я буду его реализовывать. И вряд ли у тебя получится удобнее. )

_>Ты опять же говоришь про конечный автомат написанный ради обработки кривого распараллеливания. А не ради самой предметной задачи, где конечный автомат будет и даже в полностью однопоточном случае, скажем для реализации некого протокола, формата и т.п... И для этих целей я соответственно возьму данный http://www.boost.org/doc/libs/1_59_0/libs/msm/doc/HTML/ch03s04.html#d0e1462 инструмент. Ну а что касается реализации многопоточности, то я стараюсь её писать так, чтобы там конечные автоматы (не предметные) не возникали вовсе.

ну к примеру классическая задача на inversion of control — когда данные читаются блоками по 80 байт, а выдаваться должны по 60 байт (приводилась ещё в 60-х как пример удобства сопрограмм). думаю, здесь ничего удобней них и не придумаешь

то же относится к коду архзиватора, про котолрый я тебе говорил — представляем чтение файлов, разбиение на блоки и т.д. как отдельные сопрограммы/потоки и передаём данные через связывающие их потоки сообщений. в результате каждый из потоков выполняет отдельную несложную задачу

ну и везде так — проблема автоматов в том что они с другим кодом не сочетаются, как ты из них будешь строить сложную систему?


_>Ну и да, код удобнее resp = await ask() очевидно есть. Это resp = ask().

ты просто переносишь проблему внутрь ask(). а как она будет реализована? через описание конечного автомата в виде массива переходов состояний? так await куда проще

Здравствуйте, Sinix, Вы писали:

S>Здравствуйте, alex_public, Вы писали:

S>Разумеется, это не значит, что на голый await стоит натягивать акторы.

В Unity3d натянули на yield return null. Правда, не акторы, а автоматный код скриптов.

Здравствуйте, Sinix, Вы писали:

S>Разумеется, это не значит, что на голый await стоит натягивать акторы.

Вот рассмотрим актор Player (игрок) и два варианта реализации.
В виде классического КА:

if (state == MONITORING_STATE) {
    if (enemy.getPosition().distance(player.getPosition()) < OBSERVATION_DISTANCE) {
        state = APPROACH_TO_ENEMY;
        player.MoveTo(directionToEnemy...);
    }
} else if (state == APPROACH_TO_ENEMY) {
    player.MoveTo(directionToEnemy...);
    if (enemy.getPosition().distance(player.getPosition()) < ATTACK_DISTANCE)
        state = ATTACK_STATE;
} else if (state == ATTACK_STATE) {
    //..Фаза атаки (за один фрейм)
}

С поддержкой сопрограмм код становится линейным

if (enemy.getPosition().distance(player.getPosition() < OBSERVATION_DISTANCE) {
    while (enemy.getPosition().distance(player.getPosition() > ATTACK_DISTANCE) {
        player.MoveTo(directionToEnemy...);//Смещение в направлении врага на расстояние, которое может быть пройдено за один фрейм
        yield return null;
    }
    attack(enemy, player);//Начинается атака, которая ТОЖЕ может быть записана в виде ЛИНЕЙНОГО кода
}

Как можно видеть конечный автомат при помощи сопрограмм реализован без введения трех явных состояний. При этом он вполне может оставаться конечным автоматом, то есть у него могут быть другие состояния. Просто число этих состояний можно резко уменьшить, а код сделать линейным и понятным. Повторюсь, я с помощью сопрограмм резко уменьшил при помощи одной ява-библиотеки код конечного автомата, сделав его четким и понятным.

Здравствуйте, LaPerouse, Вы писали:

LP>я с помощью сопрограмм резко уменьшил при помощи одной ява-библиотеки код конечного автомата, сделав его четким и понятным.

вот видишь, и на яве сопрограммы есть, в виде чьих-то левых библиотек. с чего тогда у тебя вознили сомнения, что даже крутейшие корпорации не смогут их реализовать, неясно

Здравствуйте, BulatZiganshin, Вы писали:

BZ>Здравствуйте, LaPerouse, Вы писали:

LP>>я с помощью сопрограмм резко уменьшил при помощи одной ява-библиотеки код конечного автомата, сделав его четким и понятным.

BZ>вот видишь, и на яве сопрограммы есть, в виде чьих-то левых библиотек. с чего тогда у тебя вознили сомнения, что даже крутейшие корпорации не смогут их реализовать, неясно

Одно дело какая-то библиотека, которой пользуются полтора человека включая автора, другое дело добавлять что-то серьезное в jre. Какие сопрограммы, в яве даже лямбды появились буквально в прошлом году.

LP>Понимаешь, Булат буквально в первом или втором посту ответил на простой вопрос про coroutines в эрланге. То, что я не смог вытянуть у тебя за два дня общения. Значит, либо Булат фантазер (как я подумал сначала и похоже ошибся), либо уровень владения тобой предметом (эрланг) оставляет желать лучшего.

Ты где-то спрашивал про то, как потоки реализованы в Эрланге? Нет. Ты спрашивал про то, как задача в Эрланге решается. Как она решается, я показал. Из этого ты нафантазировал себе какие-то далеко идущие выводы.

Пока что твой уровень общения указывает только на твое хамство, и ничего больше.

Здравствуйте, alex_public, Вы писали:

BZ>>первый поток обходит каталоги читает входные файлы
BZ>>второй поток разбивает эти данные на сжимаемые куски
BZ>>пул потоков выполняют задания на сжатие
BZ>>потоки из того же пула выполняют задания на шифрование
BZ>>послежний поток пишет готовые блоки в архив
BZ>>соответственно реализовывается всё это графом сообщений, часть задач распараллеливается в пуле потоков, часть ограничена скоростью I/O и может работать через любые асинхронные средства

_>Да, это как раз пример неплохо реализуемый с помощью модели акторов. Однако я думаю ты не сомневаешься, что он там же легко реализуется и без неё с помощью того же пула потоков. Достаточно только немного изменить схему.

нет, думаю это вообще два разных вопроса. первое — это модель переключения между потоками исполнения: потоки ОС, зелёные потоки, сопрограммы двух видов. второе — это модель их взаимодействия: акторы, графы данных, разделяемая память. соответственно, пул потоков — это лишь механизм параллельного вполнения, а акторы или графы данных прекрасно могут работать поврех них как и любого другого механизма

Здравствуйте, LaPerouse, Вы писали:

LP>Как можно видеть конечный автомат при помощи сопрограмм реализован без введения трех явных состояний.

скорее над этим находятся другие состояния поведения.
а промежуточные состояния атаки часто и не нужны.

Здравствуйте, LaPerouse, Вы писали:

_>>Конечно не представляю. ))) Я же не расставляю конечные автоматы по всему коду и по любому поводу.
LP>Я тебе верю. Ты похоже вообще слабо представляешь, что такое конечный автомат.

Конечный автомат — это полезный инструмент, но не имеющий никакого отношения к вопросам многопоточности, асинхронного кода, сопрограммам и т.п. )

_>>Вот скажем тот последний пример из первого сообщения реализуется на акторах в пару строк очевидного кода. Но мы вместо этого накрутим страшный конечный автомат на полстраницы и потом побежим на форум рассказывать про плохие акторы, которые приводят к такому дикому коду. )))
LP>Давай, жду код.

Вся указанная логика легко кодируется в несколько строк:

BOOST_MSM_EUML_TRANSITION_TABLE(( 
    State1 + Response1 [state_(data1)=event(data1),!!state_(data2)] / (process, someCommonForState1State2Processing) == State1_Processed,
    State1 + Response2 [state_(data2)=event(data2),!!state_(data1)] / (process, someCommonForState1State2Processing) == State1_Processed,
    State2 + Response1 / (doAnotherProcessing, someCommonForState1State2Processing) == State2_Processed
),transition_table)

Но только при условие, что State1, State1_Processed, State2, State2_Processed — это состояния полученные из предметной области. А не очередные последствия кривой многопоточности — тогда и от них надо избавляться.

Причём самое интересно, что к теме акторов это всё уже не имеет никакого отношения. Все эти предметные состояния и конечные автоматы были показаны только для смешного впаривания. Потому как если мы посмотрим на предлагаемый вариант работы без акторов, то увидим, что там пропадают не только никчемные состояния, появившиеся вроде как из-за акторов (а на самом деле из-за криворукости), но и предметные. Т.е. эти два примера кода не имеют между собой ничего общего.

Если же мы попробуем написать на акторах аналог предложенного кода на future (т.е. без всяких State1, State2), то увидим:

behavior actor(event_based_actor* self)
{
    optional<Data1> data1;
    optional<Data2> data2;
    return {
        [](const Data1& d) {data1=d; if(data2) process(data1, data2);},
        [](const Data2& d) {data2=d; if(data1) process(data1, data2);}
    };
}

что код становится совершенно тривиальным и без всяких конечных автоматов. Более того, при такой же краткости, как вариант с future, он при этом заметно мощнее, т.к. никто не мешает добавить в него ещё одну строчку для параллельной обработки других сообщений.

Здравствуйте, BulatZiganshin, Вы писали:

_>>Ты опять же говоришь про конечный автомат написанный ради обработки кривого распараллеливания. А не ради самой предметной задачи, где конечный автомат будет и даже в полностью однопоточном случае, скажем для реализации некого протокола, формата и т.п... И для этих целей я соответственно возьму данный http://www.boost.org/doc/libs/1_59_0/libs/msm/doc/HTML/ch03s04.html#d0e1462 инструмент. Ну а что касается реализации многопоточности, то я стараюсь её писать так, чтобы там конечные автоматы (не предметные) не возникали вовсе.
BZ>ну к примеру классическая задача на inversion of control — когда данные читаются блоками по 80 байт, а выдаваться должны по 60 байт (приводилась ещё в 60-х как пример удобства сопрограмм). думаю, здесь ничего удобней них и не придумаешь
BZ>то же относится к коду архзиватора, про котолрый я тебе говорил — представляем чтение файлов, разбиение на блоки и т.д. как отдельные сопрограммы/потоки и передаём данные через связывающие их потоки сообщений. в результате каждый из потоков выполняет отдельную несложную задачу
BZ>ну и везде так — проблема автоматов в том что они с другим кодом не сочетаются, как ты из них будешь строить сложную систему?

Ты похоже как-то странно читаешь мои сообщения, так что иногда понимаешь их наоборот что ли. ))) Сформулирую кратко по всем позициям:

1. Конечные автоматы. Предлагаю исключить их из нашей дискуссии, т.к. в данной темке есть кажется только один человек, которые предпочитает реализовывать многопоточность/асинхронность с их помощью. И это не я и не ты (вроде бы).
2. Модель акторов. Вполне мне нравится и используется. Причём частенько даже не виде специальной библиотеки, а просто как концепция, скажем поверх обычных потоков. Да, и кстати говоря идея передачи данных через сообщения идеально легла на новую C++ концепцию семантики перемещения, позволяя получить быстродействие как при работе с общей памятью, при этом не нарушая безопасности, приносимой моделью акторов. Но это естественно не универсальный инструмент реализации многопоточности/асинхронности и в определённых случаях удобнее другие инструменты (типа parallel_for и т.п.).
3. Сопрограммы. Я с ними игрался какое-то время назад (естественно с нормальными, fullstack) и видел несколько любопытных применений. Например, как уже было указано в этой темке, они позволяют переделать синхронный код в асинхронный без его модификации. Скажем сделать из boost.spirit реактивный парсер. Однако применение их для повсеместной линеаризации асинхронного кода (как это сейчас модно в C#) мне кажется не очень хорошей практикой. Та же модель акторов лишь немного уступает в краткости кода, но зато намного превосходит в его понятности.

_>>Ну и да, код удобнее resp = await ask() очевидно есть. Это resp = ask().
BZ>ты просто переносишь проблему внутрь ask(). а как она будет реализована? через описание конечного автомата в виде массива переходов состояний? так await куда проще

Нет, речь шла совсем о другом. В общем если в начале не указать в каком месте кода и в какой момент времени нам необходим resp, то весь разговор будет бессмыслен. Т.к. существуют десятки разных вариантов этих условий и для каждого будут наиболее оптимальны свои решения.

Здравствуйте, alex_public, Вы писали:

_>1. Конечные автоматы. Предлагаю исключить их из нашей дискуссии, т.к. в данной темке есть кажется только один человек, которые предпочитает реализовывать многопоточность/асинхронность с их помощью. И это не я и не ты (вроде бы).

этот человек — MS. ты похоже не в курсе async/await в c# и msvc2015

Здравствуйте, BulatZiganshin, Вы писали:

_>>Да, это как раз пример неплохо реализуемый с помощью модели акторов. Однако я думаю ты не сомневаешься, что он там же легко реализуется и без неё с помощью того же пула потоков. Достаточно только немного изменить схему.
BZ>нет, думаю это вообще два разных вопроса. первое — это модель переключения между потоками исполнения: потоки ОС, зелёные потоки, сопрограммы двух видов. второе — это модель их взаимодействия: акторы, графы данных, разделяемая память. соответственно, пул потоков — это лишь механизм параллельного вполнения, а акторы или графы данных прекрасно могут работать поврех них как и любого другого механизма

Здесь подразумевалась разделяемая память. )

Здравствуйте, BulatZiganshin, Вы писали:

_>>1. Конечные автоматы. Предлагаю исключить их из нашей дискуссии, т.к. в данной темке есть кажется только один человек, которые предпочитает реализовывать многопоточность/асинхронность с их помощью. И это не я и не ты (вроде бы).
BZ>этот человек — MS. ты похоже не в курсе async/await в c# и msvc2015

Здесь имелось в виду что-то рукопашное, типа примеров в первом сообщение темки. А async/await из C# — это всё же сопрограмма, а не конечный автомат (пусть даже она и реализована через него внутри). Собственно если мы например переделаем в следующей версии C# реализацию async/await через stackfull coroutine, то скорее всего никто этого и не заметит. )))