Здравствуйте, Ikemefula, Вы писали:
I>Но эрланговские процессы не разделяют никаких данных, то есть все взаимодействие делается через посылку сообщений.
ets
I>Как то так выходит, что пропускная способность падает, хотя время отклика худо бедно гарантируется.
ничем оно не гарантируется. там же с другой стороны зашли: гарантируется, что время ожидания не превысит указанного.
I>Но и эти гарантии сильно условные, дать больше, чем хостовая ось эрланг не сможет, а нынешние оси писали без учета потребностей эрланга
очевидно, что конфликт у них будет по умолчанию. у системных потоков свои оценки потребности переключения, у виртуалок свои.
даже питон действует похожим образом. он теперь тоже не подходит под современные оси?
I>Эту мульку быстро поняли в джаве и отказались.
как будто это кого-то спасло...
всё равно дедлоки остались проблемой при создании жава-приложений.
I>Нет способа сказать той же винде что вот эти процессы в среднем всегда готовы выполняться и что де пусть она использует для них специальный шедулер.
серьёзно? Ненужноус не умеет расставлять здраво приоритеты?
Здравствуйте, neFormal, Вы писали:
I>>Как то так выходит, что пропускная способность падает, хотя время отклика худо бедно гарантируется. F>ничем оно не гарантируется. там же с другой стороны зашли: гарантируется, что время ожидания не превысит указанного.
Это одно и то же, что время отклика, что время ожидания. При этом гарантии даёт в основном хостовая ось.
I>>Но и эти гарантии сильно условные, дать больше, чем хостовая ось эрланг не сможет, а нынешние оси писали без учета потребностей эрланга
F>очевидно, что конфликт у них будет по умолчанию. у системных потоков свои оценки потребности переключения, у виртуалок свои. F>даже питон действует похожим образом. он теперь тоже не подходит под современные оси?
Не любой, а Stackless Python. Я про него не сильно знаю.
F>всё равно дедлоки остались проблемой при создании жава-приложений.
На агентах/событиях есть ровно та же проблема, только её не называют дедлоком. Потоки необязательно останавливаются, просто часть входных запросов окажется необработаной.
I>>Нет способа сказать той же винде что вот эти процессы в среднем всегда готовы выполняться и что де пусть она использует для них специальный шедулер.
F>серьёзно? Ненужноус не умеет расставлять здраво приоритеты?
И да и нет. Она заточена под пропускную способность, а не гарантии времени отклика. Есть простой пример — 'нагружаешь' один поток с помощью Sleep(1000) и замеряешь время ожидания. При 'правильной' диспетчеризации ОС, время задержки может быть ненамного больше. В винде у меня получались отклонения ажно до 15 секунд.
Если ОС даёт гарантии реального времени, то приоритет потока к моменту пробуждения будет максимальным в системе, дополнительно решается проблема инверсии приоритетов, что в сумме дает небольшую задержку.
С т.з. времени отклика переключения должны происходить как можно чаще. С т.з. пропускной способности переключений вообще не должно быть. Эта кухня должны быть реализована начиная с низкого уровня, железа, до самого верхнего + отдельно гарантии длительности выполнения системных вызовов.
В винде ничего этого нет, а та же инверсия приорититов 'решается' варварским методом — ос пингует все спящие потоки, просто на всякий случай. Обработка аппаратных прерываний так же делается довольно варварским методом — глупый дривер или кривое устройство спокойно заблокирует тот же UI и даже мышь и тд и тд. При наличии жостких гарантий времени отклика, такое в принципе невозможно и есть ОС которые такие гарантии обеспечивают.
Здравствуйте, cures, Вы писали:
C>В архитектуре 8086 практически все регистры были к чему-то прибиты гвоздями: DS, SS — индексы в приёмнике и источнике, AX — аккумулятор, DX — расширение аккумулятора для инструкций типа умножения с делением, BX пожалуй единственный вспомогательный регистр общего назначения. А к CX прибит не только loop, но и lodsb, stosb, rep.
<offtopic>
DS и SS — сегментные регистры данных и стека соответственно. Индекс источника и приемника — SI и DI.
В принципе регистры можно было использовать, как угодно (кроме SP), учитывая факт прибития каждого из них гвоздями к чему-нибудь. И речь не о сегментных регистрах, конечно.
</offtopic>
Здравствуйте, Ikemefula, Вы писали:
I>>>Как то так выходит, что пропускная способность падает, хотя время отклика худо бедно гарантируется. F>>ничем оно не гарантируется. там же с другой стороны зашли: гарантируется, что время ожидания не превысит указанного. I>Это одно и то же, что время отклика, что время ожидания. При этом гарантии даёт в основном хостовая ось.
нет, я про то, что эрланговские процессы могут не ждать окончания ожидания.
F>>даже питон действует похожим образом. он теперь тоже не подходит под современные оси? I>Не любой, а Stackless Python. Я про него не сильно знаю.
я про подсчёт "тиков" интерпретатора. у питона оно тоже есть.
F>>всё равно дедлоки остались проблемой при создании жава-приложений. I>На агентах/событиях есть ровно та же проблема, только её не называют дедлоком. Потоки необязательно останавливаются, просто часть входных запросов окажется необработаной.
несколько странно сравнивать дедлоки с переполнением буфера. последний-то можно легко в рантайме почистить.
I>В винде ничего этого нет, а та же инверсия приорититов 'решается' варварским методом — ос пингует все спящие потоки, просто на всякий случай.
Здравствуйте, neFormal, Вы писали:
I>>Это одно и то же, что время отклика, что время ожидания. При этом гарантии даёт в основном хостовая ось.
F>нет, я про то, что эрланговские процессы могут не ждать окончания ожидания.
Это не важно, ожидают они, или сообщениями обмениваются. Принципиальной разницы нет, только форма многозадачности разная.
I>>На агентах/событиях есть ровно та же проблема, только её не называют дедлоком. Потоки необязательно останавливаются, просто часть входных запросов окажется необработаной.
F>несколько странно сравнивать дедлоки с переполнением буфера. последний-то можно легко в рантайме почистить.
При чем здесь переполнение буфера ? На акторах точно так же возникат проблемаа аналогичная дедлокам. При чем в отличие от дедлоков её гораздо сложнее изловить.
M>>Нативные потоки ОСи, доступные из Эрланга — это не приоритетное направление. Это одна их возможностей, которые добавят к языку. Года через два. А то и три. Это у них в roadmap long term: https://twitter.com/ruerlang/status/476397497863405569
I>Чисто между прочим — я вообще ничего не говорил про "нативные потоки доступные из Эрланга".
Да-да. Ты писал следующую бредятину:
В эрланге, что характерно, это (нативные треды — М.) основное направление развития.
Единственное, что есть в якобы приоритетном направлении — это нативные процессы в дальнем роадмапе, среди прочих пунктов. Завязывай нести чушь о вещах, в которых ты не разбираешься.
I>дать больше, чем хостовая ось эрланг не сможет, а нынешние оси писали без учета потребностей эрланга I>Эту мульку быстро поняли в джаве и отказались. В эрланге это основа платформы, рантайм берет на себя все мыслимы и немыслимые оптимизации
Практически единственное, что нужно Эрлангу от хостовой ОСи — это то, как быстро хостовая ОСь может отдавать/получать данные по сокету (так как Эрланг — в основном для распределенных приложений).
VM достаточно умна, чтобы минимизировать по максимуму переключения даже контекстов ядер, не то что потоков в системе (и это вдобавок еще и настраивается кучей параметров).
Поэтому Erlang вполне может именно что гарантировать soft realtime практически на любой хостовой ОСи. Вне зависимости от того, что думают об этом ничего не знающие про Эрланг люди.
Здравствуйте, Mamut, Вы писали:
I>>Чисто между прочим — я вообще ничего не говорил про "нативные потоки доступные из Эрланга".
M>Да-да. Ты писал следующую бредятину: M>
M>В эрланге, что характерно, это (нативные треды — М.) основное направление развития.
Ты пойми простую вещи — я не слежу за Эрлангом и про "нативные потоки доступные из Эрланга" узнал от тебя в этом треде.
Так понятно ?
M>Единственное, что есть в якобы приоритетном направлении — это нативные процессы в дальнем роадмапе, среди прочих пунктов. Завязывай нести чушь о вещах, в которых ты не разбираешься.
Ты наверное любой текст понимаешь только так, как тебе хочется.
Здравствуйте, Mamut, Вы писали:
M>Практически единственное, что нужно Эрлангу от хостовой ОСи — это то, как быстро хостовая ОСь может отдавать/получать данные по сокету (так как Эрланг — в основном для распределенных приложений).
Это безграмотное утверждение. Любой процесс искаропки использует целую кучу системных возможностей. Например нужно выделять память. Хочешь или нет, но это вызов ядра. Далее, у тебя нет никакого контроля над оперативной памятью — винда даёт тебе виртуальную и ты не знаешь, что это, файл или чипы. Отсюда ясно, что дисковый ввод-вывод практически неизбежен.
M>VM достаточно умна, чтобы минимизировать по максимуму переключения даже контекстов ядер, не то что потоков в системе (и это вдобавок еще и настраивается кучей параметров).
Если хостовая ОС не даёт гарантий, то VM в самом идеальном случае даст ровно тот же результат — отсутствие гарантий. Самый простой пример — ОС не переключает контекст и эрланговый поток не выполняется.
Вопрос — как VM эрланга заборет такую проблему ?
M>Поэтому Erlang вполне может именно что гарантировать soft realtime практически на любой хостовой ОСи. Вне зависимости от того, что думают об этом ничего не знающие про Эрланг люди.
Ты в курсе, что винда вообще не гарантирует, когда же контекст переключит и еще меньше гарантирует, когда нативный поток вернет управлени ? Ты в курсе, что у ней вытесняющая многозадачность ?
Для того, что бы изменить хоть как то такой расклад, VM эрланга должна в обязательном порядке вмешитьвася в работу виндовского ядра, драйверов и шедулера. Вот скажем те же сокеты требуют работу с сетью, а значит задействую чуть не всё ядро винды.
Все что ты можешь сделать на винде —
1. отключить вообще всё — приложения, сервисы, драйверы
2. увеличить по максимуму память, запретить использование свопа
3. вырубить на материнке вообще всё железо, кроме сетевого, а то железо может пользоваться шиной само по себе, даже без драйверов.
4. повысить приоритет потока эрланга до realtime(теоретически, предположим, никаких проблем это не повлечет)
Самое смешное, что даже с такими приседаниями винда принципиально не даёт никаких гарантий !
P.S. soft realtime это для тех кастомеров, которые позволяют себе лапшу на уши вешать.
P.P.S. Для тех, кто плохо умеет под винду
while(TRUE)
{
::Sleep(100);
}
Внимание — реальное время выполнения каждой итерации может варьироваться от 100мс до бесконечности.
Никакой эрланг здесь ничего принципиально не изменит и изменить не может.
Здравствуйте, Ikemefula, Вы писали:
I>Это не важно, ожидают они, или сообщениями обмениваются. Принципиальной разницы нет, только форма многозадачности разная.
неконтролируемых захват разделяемых ресурсов приводит к печальным последствиям.
я просто был свидетелем подобного пару раз. на ровном месте. от того что дизайн был не очень.
I>>>На агентах/событиях есть ровно та же проблема, только её не называют дедлоком. Потоки необязательно останавливаются, просто часть входных запросов окажется необработаной. F>>несколько странно сравнивать дедлоки с переполнением буфера. последний-то можно легко в рантайме почистить. I>При чем здесь переполнение буфера ? На акторах точно так же возникат проблемаа аналогичная дедлокам. При чем в отличие от дедлоков её гораздо сложнее изловить.
дедлоки на блокирующих вызовах? да, они действительно бывают.
но их несложно отловить. отвалится вызов по таймауту, а в стектрейсе будет причина.
там хотя бы сразу ясно, что нужно сделать для разруливания проблемы.
с мутехами, которые захватываются в разных местах, куда сложнее понять, как распутать узел желаний кодеров.
мы далековато ушли в сторону от темы, поэтому напомню:
1. на фп можно геймдевить
2. бэкэнды писать на фп проще, чем морду
3. сложнее выработать методики разработки и научить людей
Здравствуйте, neFormal, Вы писали:
I>>Это не важно, ожидают они, или сообщениями обмениваются. Принципиальной разницы нет, только форма многозадачности разная.
F>неконтролируемых захват разделяемых ресурсов приводит к печальным последствиям. F>я просто был свидетелем подобного пару раз. на ровном месте. от того что дизайн был не очень.
С акторами все тоже, только в профиль и отловить почти невозможно.
F>>>несколько странно сравнивать дедлоки с переполнением буфера. последний-то можно легко в рантайме почистить. I>>При чем здесь переполнение буфера ? На акторах точно так же возникат проблемаа аналогичная дедлокам. При чем в отличие от дедлоков её гораздо сложнее изловить.
F>дедлоки на блокирующих вызовах? да, они действительно бывают.
Я про другое, задача доступа к общему ресурсу есть вне зависимости от того, какая форма многозадачности используется. Вот у нас есть некоторый сторадж, в который запись строго упорядочена. Протокол такой — писатель начинает c begin, свой id, кучку данных, end. Мулька в том, что в этот сторадж пишут разные процессы. Читать можно тольков том случае, если все begin закрыты.
Почему именно так — вопрос не ко мне, не я это дизайнил.
Вопрос — каким образом им всем синхронизироваться ? В С++ мы тупо захватываем мутекс и пишем/читаем до посинения, потом отпускаем мутекс.
Если у нас модель акторов, то в зависимости от сложности(квалификации девелопера) можно получить целую кучу проблем. Аналог дедлока в этом случае такой — два актора шлют сообщения друг другу. Даже если вызовы неблокирующие, мы получаем проблему как с дедлоками, только вариаций больше
1 потоки спят — как с дедлоком, потому что ктото 'забыл' инициировать продолжение
2 потоки вовсю кочегарят — сообщения бегают по кругу
3 потоки работают, только некоторые логически цепочки "повисают"
4 и тд
Здравствуйте, Ikemefula, Вы писали:
F>>неконтролируемых захват разделяемых ресурсов приводит к печальным последствиям. F>>я просто был свидетелем подобного пару раз. на ровном месте. от того что дизайн был не очень. I>С акторами все тоже, только в профиль и отловить почти невозможно.
ну, это кому как. по мне, так локи на акторах отловить проще.
I>Я про другое, задача доступа к общему ресурсу есть вне зависимости от того, какая форма многозадачности используется. Вот у нас есть некоторый сторадж, в который запись строго упорядочена. Протокол такой — писатель начинает c begin, свой id, кучку данных, end. Мулька в том, что в этот сторадж пишут разные процессы. Читать можно тольков том случае, если все begin закрыты. I>Почему именно так — вопрос не ко мне, не я это дизайнил. I>Вопрос — каким образом им всем синхронизироваться ? В С++ мы тупо захватываем мутекс и пишем/читаем до посинения, потом отпускаем мутекс.
Здравствуйте, neFormal, Вы писали:
I>>Я про другое, задача доступа к общему ресурсу есть вне зависимости от того, какая форма многозадачности используется. Вот у нас есть некоторый сторадж, в который запись строго упорядочена. Протокол такой — писатель начинает c begin, свой id, кучку данных, end. Мулька в том, что в этот сторадж пишут разные процессы. Читать можно тольков том случае, если все begin закрыты. I>>Почему именно так — вопрос не ко мне, не я это дизайнил. I>>Вопрос — каким образом им всем синхронизироваться ? В С++ мы тупо захватываем мутекс и пишем/читаем до посинения, потом отпускаем мутекс.
F>захватывать весь процесс писателя?
А что значит "захватывать весь процесс писателя" с тз того же Эрланга ?
Здравствуйте, Ikemefula, Вы писали:
F>>захватывать весь процесс писателя? I>А что значит "захватывать весь процесс писателя" с тз того же Эрланга ?
эм, ну, можно сделать пул процессов-писателей(ПП), который будет возвращать pid и блокировать его от других желающих.
или просто послать в ПП сообщеньку begin, после получения которой он будет отпинывать сообщения от всех процессов, кроме текущего владельца.
те, кто не смог получить доступ, попробуют повторить попытку через некий таймаут.
Здравствуйте, neFormal, Вы писали:
F>эм, ну, можно сделать пул процессов-писателей(ПП), который будет возвращать pid и блокировать его от других желающих. F>или просто послать в ПП сообщеньку begin, после получения которой он будет отпинывать сообщения от всех процессов, кроме текущего владельца.
F>те, кто не смог получить доступ, попробуют повторить попытку через некий таймаут.
Здесь, в кратце, вместо простого мутекса вырастает или пул, или сложная логика пинания-отпинывания-блокирования. Собственно такой пул превращается фактически в асинхронный вариант того же мутекса, только он становится размазаным по коду. Как именно это облегчит отслеживание ошибки до конца не ясно.
Вообще вариантов внятной реализации много и все они, фактически, есть небольшая СМО с кучей индивидуальных свойств.
Здравствуйте, Ikemefula, Вы писали:
I>Здесь, в кратце, вместо простого мутекса вырастает или пул, или сложная логика пинания-отпинывания-блокирования. Собственно такой пул превращается фактически в асинхронный вариант того же мутекса, только он становится размазаным по коду.
ничего там не размазано
но я понимаю, что у вас там одна дырка, и ради неё делать пул смысла нет(хотя это ещё надо подумать).
сравнивать же два различных подхода применительно к одной частной проблеме, как минимум, странно.
да, там нет таких примитивов синхронизации, потому что они там не нужны. а в жаве нет ф-ции main и нужно писать целый класс, чтобы вывести `hello world`
I>Как именно это облегчит отслеживание ошибки до конца не ясно.
а ты не примешивай поиск дедлока к этой задаче.
I>Вообще вариантов внятной реализации много и все они, фактически, есть небольшая СМО с кучей индивидуальных свойств.
я не знаю нюансов вашей системы, поэтому могу говорить лишь сферически.
например, мне не нравится, что в случае с мутехами непонятно поведение, если мутех не освободят. а что, если ваш сторадж сетевой и отваливается периодически?
вопросов много, по ним принимается решение. вы для себя выбрали.
Здравствуйте, Ikemefula, Вы писали:
I>Я про другое, задача доступа к общему ресурсу есть вне зависимости от того, какая форма многозадачности используется. Вот у нас есть некоторый сторадж, в который запись строго упорядочена. Протокол такой — писатель начинает c begin, свой id, кучку данных, end. Мулька в том, что в этот сторадж пишут разные процессы. Читать можно тольков том случае, если все begin закрыты. I>Почему именно так — вопрос не ко мне, не я это дизайнил.
I>Вопрос — каким образом им всем синхронизироваться ? В С++ мы тупо захватываем мутекс и пишем/читаем до посинения, потом отпускаем мутекс.
I>Если у нас модель акторов, то в зависимости от сложности(квалификации девелопера) можно получить целую кучу проблем. Аналог дедлока в этом случае такой — два актора шлют сообщения друг другу. Даже если вызовы неблокирующие, мы получаем проблему как с дедлоками, только вариаций больше I>1 потоки спят — как с дедлоком, потому что ктото 'забыл' инициировать продолжение I>2 потоки вовсю кочегарят — сообщения бегают по кругу I>3 потоки работают, только некоторые логически цепочки "повисают" I>4 и тд
Почему просто не поставить очередь перед писателем? Так эту проблему решает CSP, так же можно решить эту проблему и здесь.
Более того, обычно в эрланге дизайн приложения строится немного по-другому: у нас есть супервайзер, который смотрит за рабочими процессами, если рабочий процесс за указанное время не осилил транзакцию, то он будет запущен снова, если это предусматривается. Сообщение наверх имеет смысл отправлять только в случае успешного завершения или смерти по таймауту.
Здравствуйте, neFormal, Вы писали:
F>а ты не примешивай поиск дедлока к этой задаче.
В этой задаче нет именно дедлока, потому ничего подмешать не получится Есть просто другая проекция той же проблемы — работа с общим ресурсом.
I>>Вообще вариантов внятной реализации много и все они, фактически, есть небольшая СМО с кучей индивидуальных свойств.
F>я не знаю нюансов вашей системы, поэтому могу говорить лишь сферически. F>например, мне не нравится, что в случае с мутехами непонятно поведение, если мутех не освободят.
Поведение как раз понятно — если не освободят, значит все потоки будут зависать на нём. Юзер-реквесты будут повисать или отваливаться по таймауту. Что касается юзер-реквестов то тоже самое будет скажем в эрланге если накосячить с пулом.
Если тот же сторадж будет отваливаться по разным причинам, то это добавляет пикантности в обоих случаях.
У акторов есть одно большое преимущество — они масштабируются. Тупо потому, что не прибиты гвоздями к кусочку памяти, как мутекс. Кроме того, акторы хорошо подстраиваются под формальные модели, то есть, человеку с должной квалификацией будет гораздо комфортнее.
Здравствуйте, m.aksenov, Вы писали:
MA>Почему просто не поставить очередь перед писателем? Так эту проблему решает CSP, так же можно решить эту проблему и здесь.
Мы говоли не про то, как надо писать, а сравнивали возможные проблемы из за некорректного кода.
Дедлок == некорректный код. Я привел его аналог, т.е. некорректное решения в модели акторов.
Есть просто другая проекция той же проблемы — работа с общим ресурсом.