LINUX.ORG.RU

Вопрос по архитектуре: одопоточность vs треды vs another_stuff

 


0

1

Асинхронность JS, имхо, являтся половинчатым решнием. Если я правильно понимаю, она избавляет нас только от одного — от бесполезного простоя машины: машина не ждет, когда закончится блокирующая операция, она все время занята. Однако, это не избавляет от ожидания самого пользователя: если машина занята, она блокирует единственный поток, и не реагирует на события своевременно (ставит их в очередь).

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

Такая архитктура, мне кажется, самоочевидна. Это напоминает модель акторов, вроде. Однако, я не вижу, чтобы это активно применялось. Почему?

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

Собственно вопрос: почему так называемые «архитекторы» не пошли по простому и очевидному пути? Тут снова мы сталкивамся с математикой головного мозга компьютер-сайентологов, которые думали, что волшебные лямбды избавят их от проблем масштабируемости, или это просто тупость?

«event-driven» это методология написания кода, которая чуть менее чем никак не относится к его исполнению

buddhist ★★★★★ ()
Ответ на: комментарий от buddhist

Хорошо, щас поправлю. А как правильно называть? Событийно-ориентированная модель?

anonimous ()
Ответ на: комментарий от buddhist

«event-driven» это методология написания кода, которая чуть менее чем никак не относится к его исполнению
Событи́йно-ориенти́рованное программи́рование (англ. event-driven programming; в дальнейшем СОП) — парадигма программирования, в которой выполнение программы определяется событиями — действиями пользователя (клавиатура, мышь), сообщениями других программ и потоков, событиями операционной системы (например, поступлением сетевого пакета).

Где тут про методологию написания кода независимую от исполнения написано?

anonymous ()
Ответ на: комментарий от anonymous

выполнение программы

поведение программы

Выполняться оно может хоть на кластере из китайцев так, как им вздумается

buddhist ★★★★★ ()
Ответ на: комментарий от buddhist

Ты пишешь программу и н знаешь, как она себя будет вести?

anonymous ()
Ответ на: комментарий от anonymous

Семантика поведения программы соответствует семантике языка, на котором она написана, семантика исполнения программы соответствует семантике исполнителя.

buddhist ★★★★★ ()
Ответ на: комментарий от buddhist

Ты хоть сам то понимаешь, что ты говоришь? Исполнитель текста программы - это и есть исполнитель языка. Исполнитель непосредственно программы — условно, разве что процессор. Какая нах семантика? Семантика головного мозга.

anonymous ()
Ответ на: комментарий от anonymous

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

Грубо говоря, ивенты существуют у тебя в голове и в языке, на котором ты пишешь. А реализовано это может быть через треды, через процессы, так, как предлагает ТС, да как угодно, лишь бы внешняя семантика сохранилась. Пусть хоть твоя скомпилированная программа вообще имеет огромную таблицу соответствия: «внешние данные — код, который нужно выполнить/ответ, который нужно вернуть».

buddhist ★★★★★ ()
Ответ на: комментарий от buddhist

Ну, вот допустим, есть 2 языка с разными моделями исполнения: асинхронная однопоточная и многопоточная. Пусть в обоих языках есть инструкция onEvent, и она означает в обоих семантиках то ж самое — повесить на событие действие. В обоих языках мы пишем такие программы: onEvent=longCalculation. Допустим, юзер инициировал этот event. Пошло вычисление. В однопоточной модели, это вычислние заблокирует обращения других пользователей. Это значит, что, допустим, запрос длает Вася, Васин запрос обрабатывается, в это время ломится запрос Пети, который становится в очередь. Дождется ли Петя окончания обработки запроса Пети? Если бы была многопоточность, обработка запроса Пети началась бы моментально. Если, допустим, обработка Васиного запроса занимает час, Петя не будет ждать.

Что мы имеем в сухом остатке? То, что «семантически» эквивалентные в разных языках конструкции «onEvent» приводят к различным рзультатам. И как же, в таком случае можно говорить о «внешняя семантика сохранилась». Никак. Вншняя, как ты говоришь, семантика по-любому зависит от реализации, мы имем 2 разных результата: «Петя получил ответ» и «Петя НЕ получил ответ». Поэтому все высоколобые рассуждния об эквивалентности семантик — есть ни что иное как демагогия. Математические выкладки всегда противоречат реальности, когда вопрос касается времени.

anonymous ()
Ответ на: комментарий от buddhist

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

anonymous ()
Ответ на: комментарий от anonymous

Петя не будет ждать

Его проблемы, если семантика исходного языка не гарантирует ему фиксированное время выполнение

buddhist ★★★★★ ()

Собственно вопрос: почему так называемые «архитекторы» не пошли по простому и очевидному пути?

Почему не пошли? Всё это есть. В NEXTSTEP выбрали такой подход, о котором пишешь ты, и реализовали это всё в Objective-C runtime. Можно вызывать методы на других машинах как на своей, удалённо, через сеть. Microsoft тоже разработала RPC, причём несколько разновидностей. Из открытых и современных средств разработки есть Erlang и его VM, которая спроектирована ИМЕННО для такой архитектуры, о которой пишешь ты. А треды или они же потоки, это параллелизация на одной машине, с многоядерной архитектурой, где важны минимальные задержки и быстрое прееключение между потоками, чего не сделаешь так же качественно на нескольких машинах сразу в едином пуле.

menangen ★★★★★ ()
Последнее исправление: menangen (всего исправлений: 1)

что-то вот это не понятно:

если машина занята, она блокирует единственный поток

это почему? есть же шедулер, он не даст всему стать колом.

Такая архитктура, мне кажется, самоочевидна. Это напоминает модель акторов, вроде. Однако, я не вижу, чтобы это активно применялось. Почему?

Еще как применяется в играх и финансовой сфере

падние производительности на больших нагрузках и дедлоки

Если ты про треды, то наоборот, работа с разделяемой памятью - это единственный способ выжать из CPU по-максмуму. Память медленней CPU, нужно всегда об этом помнить. Shared-nothing - это хорошо, но не супер-эффективно для CPU-intensive задач, это скорее для IO-intensive.

dizza ★★★★★ ()
Ответ на: комментарий от dizza

это почему? есть же шедулер, он не даст всему стать колом.

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

anonimous ()

Топик не читай - сразу отвечай.

Почему?

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

Lilly ()
Ответ на: комментарий от anonimous

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

dizza ★★★★★ ()
Последнее исправление: dizza (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.