I>>Мне бы тоже хотелось узнать, как эрланг обеспечивает реалтаймные гарантии, с его fault-tolerance искаропки.

S>Выше уже кто-то, вроде бы Wolfhound уже поднимал тему производительности selective receive.

То, что Вулфхаунд поднимал, произошло один раз 7 лет тому назад. Только почему то и он и ты делаете из этого какие-то далеко идущие выводы

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

M>То, что Вулфхаунд поднимал, произошло один раз 7 лет тому назад. Только почему то и он и ты делаете из этого какие-то далеко идущие выводы
Только в этой теме ещё один пример привели. Но тебе же пофиг.
Re[8]: Mногопоточность: C++ vs Erlang vs другие

Автор: netch80
Дата: 13.06.15

M>>То, что Вулфхаунд поднимал, произошло один раз 7 лет тому назад. Только почему то и он и ты делаете из этого какие-то далеко идущие выводы
WH>Только в этой теме ещё один пример привели. Но тебе же пофиг.
WH>Re[8]: Mногопоточность: C++ vs Erlang vs другие

Автор: netch80
Дата: 13.06.15

Да. Мне — пофиг. Потому что этот пример не от «я д'Артаньян, вы — тупые» тебя, а от людей, которые понимают, о чем говорят.

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

M>Да. Мне — пофиг. Потому что этот пример не от «я д'Артаньян, вы — тупые» тебя, а от людей, которые понимают, о чем говорят.
То есть ты соврал и тебе пофигу, что ты соврал. Прэлэсно.

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

S>А то, что на самом деле I = I + 1 в интересных нам приложениях означает I = GetRemoteResource("I"); SetRemoteResource("I", I.Add(GetRemoteResource("1"));, где каждая из трёх операций — это долгое ожидание, он предпочитает игнорировать.

ОМГ. ))
Я предпочитаю озвучить ТЗ, потому что это иначе спекуляции.

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


S>Потому что если это перестать игнорировать, то отсутствие yield/await между операциями означает, что мы блокируем исполнитель на это время.

Немного не так.
Вот был пример с файлом от Ikemefula, в котором некие байты были по-разному записаны. Т.к. от Ikemefula бесполезно ждать объяснения, что там с байтами не так, т.е. бесполезно ждать ТЗ, давай я предложу некое ТЗ.

Итак. Есть задача писать в файл некие сообщения. Пусть сообщение представлено типом-кодом и телом, где разметка тела полностью определяется типом сообщения, т.е. как-то так: {typeCode1:8, field1:16, field2:64 }, { typecode2:8, field:128 } и т.д., где N в записи ':N' означает некую разрядность в разметке сообщений и используется исключительно в кач-ве примера наличия разных разметок разных сообщений.

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

Вопрос, нужны ли в случае жабасрипта критические секции, мьютексы и т.д. для этой задачи?
Я даже расширю вопрос (специально для Ikemefula) — нужны ли, помимо обычных мьютексов хотя бы даже т.н. "асинхронные" мьютексы? ))


S>И в вытесняющей многозадачности это ещё работает хоть как-то

Это работает и в кооперативной. Причем, давний спор с Ikemefula был именно относительно того, что именно в кооперативной многозадачности можно обходиться без мьютексов, если известно, что все кооперативные "одновременные" потоки, обращающиеся к одному и тому же ресурсу, сидят поверх одного потока ОС, как в жабаскрипте.


S>и все остальные 99999 тасок встанут в ожидании окончания сетевого обмена с ресурсами "I" и "1".

Ох, ну и детсад попер уже.
Если требуется некая транзакционность при работе с удалённым ресурсом, то, в зависимости от вида транзакционности, обеспечиваемой удалённым ресурсом, мы можем нарваться на идентичные сценарии даже в твоей "кооперативной" многозадачности, где остальные таски, зависимые от этого ресурса, в любом случае будут ждать ресурс. Ууупс?

Вот тут стоит помедитировать, где и на чём ты попытался спекулировать. Уж ты-то должен понять, где в твоих рассуждениях слабина. ))

И да. Я лишь настаивал на том, что кооперативную многозадачность можно выразить через вытесняющую, где весь код от yield до yield обложен парой disable interruptions / enable interruptions. И предлагаю пользоваться этим знанием, а не показательно его игнорить, впадая вот в такую ересь.

Ересь, потому что получается, что вы пытаетесь возражать не на мои вполне однозначные утверждения, а на некие свои фобии, которые вообще никак с моими утверждениями не связаны.

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

V>Пусть у нас есть несколько логических потоков в жабаскрипте (т.е. несколько async-методов), в которых мы генерируем и записываем в файл эти сообщения "одновременно". Требуется организовать процесс записи файла так, чтобы каждое сообщение было записано в файл целиком, кароч, чтобы в результирующем файле у нас не возникла "каша" из перекрывающихся тел сообщений.

V>Вопрос, нужны ли в случае жабасрипта критические секции, мьютексы и т.д. для этой задачи?

я посмотрел windows.h от win 3.1 — не было там никаких CS и прочих мьютексов. в условиях одноядерного cpu и кооперативной многозадачности это было ни к чему — скажем CS можно реализовать так:

volatile bool flag = false;
//...
while(flag) Yield();
flag=true;
//тело секции
flag=false;

и на твой вопрос ответ — нет. при использовании синронных операций работы с файлами это ничем не отличается от записи в одном потоке

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

V>ОМГ. ))
V>Я предпочитаю озвучить ТЗ, потому что это иначе спекуляции.
Какое ТЗ? Речь идёт о целом классе задач, у которых есть характерные общие черты.

V>Потому как иначе получается, что ты тоже умудрился много чего проигнорировать, например, то, что сама операция SetRemoteResource должна быть атомарной, например, для случая, когда тип I представлен значением, которое не записывается в своё хранилище за одну операцию процессора. Как эту атомарность обеспечивать будем в случае жабасрипта?
Ну, если у нас есть готовое решение для обеспечения атомарности всего блока, то уж наверное можно его применить и к отдельной операции, нет?

V>Итак. Есть задача писать в файл некие сообщения. Пусть сообщение представлено типом-кодом и телом, где разметка тела полностью определяется типом сообщения, т.е. как-то так: {typeCode1:8, field1:16, field2:64 }, { typecode2:8, field:128 } и т.д., где N в записи ':N' означает некую разрядность в разметке сообщений и используется исключительно в кач-ве примера наличия разных разметок разных сообщений.

V>Пусть у нас есть несколько логических потоков в жабаскрипте (т.е. несколько async-методов), в которых мы генерируем и записываем в файл эти сообщения "одновременно". Требуется организовать процесс записи файла так, чтобы каждое сообщение было записано в файл целиком, кароч, чтобы в результирующем файле у нас не возникла "каша" из перекрывающихся тел сообщений.

V>Вопрос, нужны ли в случае жабасрипта критические секции, мьютексы и т.д. для этой задачи?
Всё зависит от того, есть ли у нас гарантия единственности системного потока, в котором бегут эти логические потоки. Потому что если вдруг VM начала использовать N потоков (или если мы тупо запустили 2 инстанса VM на одной машине), то без примитивов мы получаем гарантию мусора.

V>Это работает и в кооперативной. Причем, давний спор с Ikemefula был именно относительно того, что именно в кооперативной многозадачности можно обходиться без мьютексов, если известно, что все кооперативные "одновременные" потоки, обращающиеся к одному и тому же ресурсу, сидят поверх одного потока ОС, как в жабаскрипте.
Да, это так. Но вот эту уверенность лучше основывать на чём-то надёжнее, чем "я пока ни разу такого не видел". Потому что я видел много "многопоточного" кода, который уверенно работал ровно до момента запуска на многоядерной машине.

V>Если требуется некая транзакционность при работе с удалённым ресурсом, то, в зависимости от вида транзакционности, обеспечиваемой удалённым ресурсом, мы можем нарваться на идентичные сценарии даже в твоей "кооперативной" многозадачности, где остальные таски, зависимые от этого ресурса, в любом случае будут ждать ресурс. Ууупс?
Ну, для этого придётся специально постараться. Но это будет ожидаемым поведением — важное выделено. В наивной реализации блокируюшего IO заблокируется вообще весь мир, а не только зависимые таски.

V>И да. Я лишь настаивал на том, что кооперативную многозадачность можно выразить через вытесняющую, где весь код от yield до yield обложен парой disable interruptions / enable interruptions. И предлагаю пользоваться этим знанием, а не показательно его игнорить, впадая вот в такую ересь.
Выразить можно всё, что угодно. Просто обычно вытесняющая многозадачность — адски дорогая. Поэтому лучше иметь кооперативную многозадачность с примитивами синхронизации.

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

S>>Выше уже кто-то, вроде бы Wolfhound уже поднимал тему производительности selective receive. Если receive не дает никаких временных гарантий, то про реал-тайм вообще можно забыть. Но и кроме receive важен вопрос количества поддерживаемых VM приоритетов для процессов и способы защиты от priority inversion. И как это все сочетается с необходимостью использовать C-шные NIF-ы или даже драйвера, когда производительности pure-Erlang кода не хватает.

S>Простите, а что вы все к real-time'у в контексте Эрланга привязались. real-time -- это ограничение на io сверху. Их венда
S>и линупс дать не могут, какой уж тут Эрланг.

Мамут яростно утверждает, что на любой системе Эрланг даёт те самые гарантии.

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

V>Потому как иначе получается, что ты тоже умудрился много чего проигнорировать, например, то, что сама операция SetRemoteResource должна быть атомарной, например, для случая, когда тип I представлен значением, которое не записывается в своё хранилище за одну операцию процессора. Как эту атомарность обеспечивать будем в случае жабасрипта?

Ты хочешь снова перепрыгнуть на i = i + 1

S>>Потому что если это перестать игнорировать, то отсутствие yield/await между операциями означает, что мы блокируем исполнитель на это время.

V>Немного не так.
V>Вот был пример с файлом от Ikemefula, в котором некие байты были по-разному записаны. Т.к. от Ikemefula бесполезно ждать объяснения, что там с байтами не так, т.е. бесполезно ждать ТЗ, давай я предложу некое ТЗ.

V>Пусть у нас есть несколько логических потоков в жабаскрипте (т.е. несколько async-методов), в которых мы генерируем и записываем в файл эти сообщения "одновременно". Требуется организовать процесс записи файла так, чтобы каждое сообщение было записано в файл целиком, кароч, чтобы в результирующем файле у нас не возникла "каша" из перекрывающихся тел сообщений.

Неверно. Нужно получить коректную последовательность сообщений, когда одно сообщение пишется-по-частям:

Вот типичный таск

while(condition) {
  var chunk  = yield getRemoteResource(i)
  yield write(chunk)
}

т.е. сначала все кусочки одной задачи, за ними все кусочки другой задачи и тд и тд.

S>>И в вытесняющей многозадачности это ещё работает хоть как-то

V>Это работает и в кооперативной. Причем, давний спор с Ikemefula был именно относительно того, что именно в кооперативной многозадачности можно обходиться без мьютексов,

Спор был ровно о том же, что и сейчас — откуда берутся гонки в JS и как с ними бороться в случае с
1 асинхронными
2 длинными(из множества цепочек)
3 параллельными (много аналогичных задач работает над тем же ресурсом)
операциями.

V>Если требуется некая транзакционность при работе с удалённым ресурсом, то, в зависимости от вида транзакционности, обеспечиваемой удалённым ресурсом, мы можем нарваться на идентичные сценарии даже в твоей "кооперативной" многозадачности, где остальные таски, зависимые от этого ресурса, в любом случае будут ждать ресурс. Ууупс?

Можно, но весь вычислитель целиком не останавливается. Те, что ждут, пусть ждут, это нормально, раз уж сам ресурс имеет такой протокол.

V>И да. Я лишь настаивал на том, что кооперативную многозадачность можно выразить через вытесняющую, где весь код от yield до yield обложен парой disable interruptions / enable interruptions. И предлагаю пользоваться этим знанием, а не показательно его игнорить, впадая вот в такую ересь.

Поздравляю, ты изобрёл мутекс.

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

V>>Вопрос, нужны ли в случае жабасрипта критические секции, мьютексы и т.д. для этой задачи?

BZ>я посмотрел windows.h от win 3.1 — не было там никаких CS и прочих мьютексов.

А как по твоему два процесса смогут работать с одним файлом, что бы гарантировать определенную последовательность записей ?

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

V>>>Вопрос, нужны ли в случае жабасрипта критические секции, мьютексы и т.д. для этой задачи?

BZ>>я посмотрел windows.h от win 3.1 — не было там никаких CS и прочих мьютексов.

I>А как по твоему два процесса смогут работать с одним файлом, что бы гарантировать определенную последовательность записей ?
I>

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

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

S>>Простите, а что вы все к real-time'у в контексте Эрланга привязались. real-time -- это ограничение на io сверху. Их венда
S>>и линупс дать не могут, какой уж тут Эрланг.

I>Мамут яростно утверждает, что на любой системе Эрланг даёт те самые гарантии.

Ну я от него слышал обещание только про soft realtime. В моём понимании это означает статистически достоверные гарантии. Ну и не на любой системе, а при определённых условиях типа "LA<=4, свопа не более 1GB, etc."
Всё-таки все мы тут под богом в Mach-styled VM работаем.

Собственно весь дискурс не в том, что он вообще это обеспечивает, а в том, что он это обеспечивает вместе со всеми прочими своими плюшками и несмотря на них.

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

V>>>Про это тоже идут споры не один десяток лет. TCP для HTTP — это для 99% сценариев из пушки по воробьям. Давно уже высказывались мысли, что для HTTP больше подойдет message-oriented протокол, но, в отличие от UDP, чтобы гарантировалась доставка.
N>>Если бы это было серьёзной проблемой, давно бы в винде встроили SCTP из коробки.
V>Причем тут SCTP?

Message-oriented с гарантией доставки, всё, как ты просил. При этом стандартный с несколькими вылизанными реализациями.
Или скажешь, что он имеет "фатальный недостаток" (tm)?

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

I>>>Правильно. Потому ручная диспетчеризация асинхронного кода — адский АДъ. В многопоточном коде ты можешь остановить все потоки и глянуть, что же там не так. В асинхронном коде у тебя такого фокуса нет. И многих других — тоже нет.
N>>Мнэээ... а вот тут уже непонятно. А почему нельзя?
I>В нативных тредах у тебя есть колстек. В асинхронном коде его нет ни капли. Что откуда каким путём пришло — ахез.

А что, коллстек стал панацеей? Если у тебя уже мусор в данных, а откуда он появился, неизвестно, все подробности генерации давно забылись — у тебя на руках только мусор с момента его осознания таковым.
Я действительно не вижу разницы. Если тебе нужны в рантайме какие-то подробности о происходящем, их можно вложить в контекст (например, через хитроназванные ключи объектов). Но для процедурного те же проблемы.

I>Если ты остановил все треды, скажем в дотнете или плюсах, то анализ колстека дает тебе почти всю информацию.

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

N>>У шедулера такого кода есть в явном виде очередь отложенных задач, которые чего-то ждут (внешнего события или просто таймера). Остановить их всех — задача чисто техническая. Манипулировать этой очередью на ходу — тоже.
I>Не получится чесно остановить тот же http.get. И здесь другой фокус- как только отпускаешь отладчик, получаешь автоматом вырожденный кейс, когда респонсы валятся лавиной.

А что, с остановкой всех тредов ты его не получаешь?

I>Другая проблема — нет способа отлаживать ровно одну логическую з
I>>>Не только не послали, но и активно развивают это направление. Ибо — дёшево.

N>>Надеюсь, до определённого количества таких отпуливаний? Потому что зациклить таки элементарно.

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

I>Как то так сложилось, что многие авторитетные источики пропагандируют идеи "в асинхронном коде гонок нет", "дедлоки не бывают" и потому контингент обкладывает control flow разными флажками и тд и тд.
I>Фактически получаются те же мутексы, только размазаные по коду.

Тут категорически согласен.

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

N>А что, коллстек стал панацеей? Если у тебя уже мусор в данных, а откуда он появился, неизвестно, все подробности генерации давно забылись — у тебя на руках только мусор с момента его осознания таковым.
N>Я действительно не вижу разницы. Если тебе нужны в рантайме какие-то подробности о происходящем, их можно вложить в контекст (например, через хитроназванные ключи объектов). Но для процедурного те же проблемы.

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

I>>Если ты остановил все треды, скажем в дотнете или плюсах, то анализ колстека дает тебе почти всю информацию.
N>Ха тире ха, три раза. Порушенная куча, затёртые данные в переменных, забытые ссылки, и всё это уже час засоряет память.

В многопоточном коде я бы сказал 70-80% проблем решаются с помощью этого фокуса. Если проблема с забытыми ссылками, здесь, опять же, помогает колстек — в том же профайлере.

I>>Не получится чесно остановить тот же http.get. И здесь другой фокус- как только отпускаешь отладчик, получаешь автоматом вырожденный кейс, когда респонсы валятся лавиной.

N>А что, с остановкой всех тредов ты его не получаешь?

Полчаешь, только ручной работы несравнимо меньше"

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

N>Ну я от него слышал обещание только про soft realtime. В моём понимании это означает статистически достоверные гарантии. Ну и не на любой системе, а при определённых условиях типа "LA<=4, свопа не более 1GB, etc."
N>Всё-таки все мы тут под богом в Mach-styled VM работаем.

N>Собственно весь дискурс не в том, что он вообще это обеспечивает, а в том, что он это обеспечивает вместе со всеми прочими своими плюшками и несмотря на них.

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

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

I>>А как по твоему два процесса смогут работать с одним файлом, что бы гарантировать определенную последовательность записей ?
I>>

N>Называть файловые локи мьютексами это сильно. Хотя с точки зрения всепоглощающего дзена я, пожалуй, соглашусь. В этом смысле они были и в ms-dos, поверх файлопомоечных сетейю

Да, файл это плохой пример, там действительно лок есть сам по себе, если в эксклюзивном доступе открывать.
Как быть с шареным доступом ?

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

EP>Тоже самое например происходит в показанном ранее примере C# — обрати внимание на исходный код с await, на переменную result, и на поле <result>5__1 в сгенерированном коде

Я тебе на это уже отвечал — на примере C# видно, что корутина (произвольного размера) создаётся в куче, реализует некий публичный интерфейс, а локально мы имеем лишь ссылку на этот интерфейс.

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


V>>Где будет хранится локальная переменная tmp в твоём случае, т.е. когда iterator<> — это полностью value-type объект?
EP>Она будет хранится внутри объекта-автомата, который будет хранится внутри самого итератора. Естественно тип итератора будет зависеть от типа класса-автомата.

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

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

I>>>А как по твоему два процесса смогут работать с одним файлом, что бы гарантировать определенную последовательность записей ?
I>>>
N>>Называть файловые локи мьютексами это сильно. Хотя с точки зрения всепоглощающего дзена я, пожалуй, соглашусь. В этом смысле они были и в ms-dos, поверх файлопомоечных сетейю
I>Да, файл это плохой пример, там действительно лок есть сам по себе, если в эксклюзивном доступе открывать.
I>Как быть с шареным доступом ?

А как с ним быть? В СУБД типа всех этих Clipper, FoxPro, etc. эту тему отработали.
Локи на чтение, локи на запись, и полный подарочный комплект связанных с ними граблей.
Кстати, кажется, там lock upgrade/downgrade не был предусмотрен, и иногда было неудобно.

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

I>>Да, файл это плохой пример, там действительно лок есть сам по себе, если в эксклюзивном доступе открывать.
I>>Как быть с шареным доступом ?

N>А как с ним быть? В СУБД типа всех этих Clipper, FoxPro, etc. эту тему отработали.

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