LINUX.ORG.RU
ФорумTalks

Синхронные IPC vs Асинхронные IPC


0

0

Почти 8 часов утра, а значит пора ложиться спать. :) Но перед сном хотелось бы задать небольшую тему для обсуждения.

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

Почему? Используя асинхронные IPC:

во первых, появляется необходимость для хранения промежуточных данных. Это повышает накладные расходы;

во вторых, в случае обработки потоков данных, потребуется вручную реализовывать синхронизацию. Это лишние костыли;

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

p.s. Не стоит инвертировать мои аргументы.

p.p.s. Встретимся через 8 часов. :)

★★★

Давайте ответим топикстартеру "каждой задаче свои инструменты" и закроем тему, пусть через 8 часов здесь ни одного нового сообщения не появится.

fmj
()

Давайте ещё поднимем вопрос "Молотки vs. Дрели", "Ножовки vs. Отвёртки". Топикстартер - пионер, всему свой инструмент.

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

А я вот еще что скажу: каждой задаче - свой инструмент. Теоретически и на "Ниве" можно пахать, а на К-700 - ездить на рыбалку.

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

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

berrywizard ★★★★★
()

Еще можно добавить, что асинхронные IPC элементарно выражаются через синхронные. Доказано Хоаром.

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

> Давайте ответим топикстартеру "каждой задаче свои инструменты" и закроем тему, пусть через 8 часов здесь ни одного нового сообщения не появится.

Ага. С учётом того, что на основе одних, можно реализовать другие, я предпочту из синхронных сделать асинхронные, нежели наоборот.

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

> Давайте ещё поднимем вопрос "Молотки vs. Дрели", "Ножовки vs. Отвёртки". Топикстартер - пионер, всему свой инструмент.

Пионер - это ты. Ибо своего мнения не имеешь, а повторяешь за предыдущим постером.

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

> А я вот еще что скажу: каждой задаче - свой инструмент. Теоретически и на "Ниве" можно пахать, а на К-700 - ездить на рыбалку.

У тебя уже третья "оригинальная" мысль. А по делу есть что сказать?

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

> ну вообще-то, для каждой задачи свой, под неё заточенный инструмент, оптимальней. можно на тарантайке из гольф-клуба руду из карьера возить, а на "урагане" в магазин ездить, но смысл?

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

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

> Интересно, чем навеяны данные выводы ?

Экспиренс. Хотя, многие разработчики "русских ОС" гордятся, что их система (будет) построена на асинхронных IPC. Тема для них - гордиться нечем.

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

> человек открыл для себя pthread_create() ? :)

Так точно. Лет, эдак, семь назад.

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

> Еще можно добавить, что асинхронные IPC элементарно выражаются через синхронные. Доказано Хоаром.

А я, как бы, не отрицаю этот факт.

<offtopic> Мобилы зло - выспаться не удалось. :( </offtopic>

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

А зачем DMA, когда есть PIO и можно любое устройство опрашивать, пока оно не закончит работу, подумаешь, что ресурсы будут тратиться на опрос в цикле ;)

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

> А зачем DMA, когда есть PIO и можно любое устройство опрашивать, пока оно не закончит работу, подумаешь, что ресурсы будут тратиться на опрос в цикле ;)

Пример отличный, но он как раз подтверждает правильность асинхронных IPC. Ибо без семафора при асинхронности как раз и получится "опрос в цикле".

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

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

а как проверить состояние семафора из юзерспейса, только опросом в цикле... ??

p.s. видимо я чего-то не понимаю

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

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

В CSP его можно интерпретировать как вывод процессом "CPU" значения в канал "IRQn" :)

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

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

Это асинхронное взаимодействие. Но...

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

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

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

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

> гарантировано, что обработчик сообщения не прерывается

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

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

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

А что в итоге, ультраНЕмасштабируемая реализация сервиса, либо если масштабируемая, то распухшая до такого состояния, таких размеров, что ни один гик в нем уже нифига не поймет :) (Вспомните дискуссию Торвальдса с Тененбаумом, про однопоточную реализацию fs в виде сервиса на микроядерной системе)

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

>> гарантировано, что обработчик сообщения не прерывается

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

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

Кстати говоря, именно так реализована обработка IRQ в Mac OS X, большая часть прерываний обрабатывается потоками с RT приоритетами, большую часть времени спящими, если приходит IRQ, фактический IRQ-handler лишь помечает соотвествующий поток, как готовый к исполнению, и по завершению обработки IRQ, управление сразу-же переходит к этому потоку. Однако не все так сладко, для ряда устройств, где очень критично время отзыва, первичная обработка IRQ происходит непосредственно в контексте IRQ прерывания. Ну и стоит отметить, что данный подход используется только для прерываний, в остальных местах в OS X он как-то не прижился.

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

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

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

> Не говоря уже о параллельной работе множества нитей, обрабатывающих сообщения одного и того же типа.

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

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

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

> А что в итоге, ультраНЕмасштабируемая реализация сервиса, либо если масштабируемая, то распухшая до такого состояния, таких размеров, что ни один гик в нем уже нифига не поймет :)

Неправда твоя. Первая часть твоего утверждения - вызывающе неверная информация, а вот со второй соглашусь.

В итоге получается _ультрамасштабируемая_ реализация сервиса, но не распухшая, а сложная в реализации.

> (Вспомните дискуссию Торвальдса с Тененбаумом, про однопоточную реализацию fs в виде сервиса на микроядерной системе)

Не поверишь, у меня есть такая реализации.

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

> Кстати говоря, именно так реализована обработка IRQ в Mac OS X, большая часть прерываний обрабатывается потоками с RT приоритетами, большую часть времени спящими, если приходит IRQ, фактический IRQ-handler лишь помечает соотвествующий поток, как готовый к исполнению, и по завершению обработки IRQ, управление сразу-же переходит к этому потоку.

Вероятно, ноги растут из Mach.

> Однако не все так сладко, для ряда устройств, где очень критично время отзыва, первичная обработка IRQ происходит непосредственно в контексте IRQ прерывания.

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

> Ну и стоит отметить, что данный подход используется только для прерываний, в остальных местах в OS X он как-то не прижился.

Лень разработчиков.

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

>> Однако не все так сладко, для ряда устройств, где очень критично время отзыва, первичная обработка IRQ происходит непосредственно в контексте IRQ прерывания.

> Это проблемы современных микропроцессоров

о йопт, причем здесь микропроцессоры? O_O

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

> о йопт, причем здесь микропроцессоры? O_O

Потому что вышеописанный метод организации прерывания посредством IPC может быть (должен и, вероятно, будет) реализован в железе.

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

Ыыыыы... ты вообще читаешь, что тебе пишут? "устройств, где очень критично время отзыва" - ты что, обработку прерываний запихнешь прямо в устройство? o_O

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

> ты вообще читаешь, что тебе пишут? "устройств, где очень критично время отзыва" - ты что, обработку прерываний запихнешь прямо в устройство?

Be calm. Пожалуйста, пример устройства.

Представь, что у x86 процессора появилась новая команда - IPC. Таблица векторов прерываний должна уйти в прошлое. Иными словами, новое содержимое этой таблицы - список ID нитей, которые сопоставлены каждому прерыванию.

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

> В итоге получается _ультрамасштабируемая_ реализация сервиса, но не распухшая, а сложная в реализации.

В чем же масштабируемость? Она будет получать выгоду, от того, что вместо 1-ого CPU на этот сервис отведут 16? Очевидно, если вся обработка ведется в пределах 1-ой нити, то нет, а выйти за пределы 1-ой нити вы сами себе не позволили, избавившись от синхронизации :) Это один аспект немасштабируемости. Второй аспект немасштабируемости, это высокая алгоритмическая сложность переноса под подобную архитектуру сервисов с других OS, прийдется городить такой огород, что мало не покажется, и при этом внутри сервиса, опять-же будет асинхронно-событийный механизм использоватся, для демультеплексирования событий различных, пусть все это и будет крутится "в большом синхронном select-е".

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

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

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

>> Ну и стоит отметить, что данный подход используется только для прерываний, в остальных местах в OS X он как-то не прижился.

> Лень разработчиков.

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

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

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

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

Если брать "непрерывные обработчики прерывания" - поди задай им приоритет. А уж приоритет самого обрабатываемого прерывания тут уж и вовсе ни при чем.

>> Не говоря уже о параллельной работе множества нитей, обрабатывающих сообщения одного и того же типа.

> Какая гадость и мерзость, пожалей мою клавиатуру - щас заблюю. А теперь, внимание:

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

(участливо) Ну что, проблевался? А теперь докажи то, что понаписал.

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

> Представь, что у x86 процессора появилась новая команда - IPC. Таблица векторов прерываний должна уйти в прошлое. Иными словами, новое содержимое этой таблицы - список ID нитей, которые сопоставлены каждому прерыванию.

А теперь представь, что отправителей таких сообщений в системе множество, другом конце команды IPC сидит не один обработчик твоих сообщений, а опять же множество, и при этом твоё сообщение будет требовать 100 дней на обработку (ну оно и час может требовать и минуту - всё равно это непомерно долго для проца висеть на вызове команды IPC).

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

>> ты вообще читаешь, что тебе пишут? "устройств, где очень критично время отзыва" - ты что, обработку прерываний запихнешь прямо в устройство?

> Be calm. Пожалуйста, пример устройства.

Это вопрос к Эпплу. Допустим, что устройство всего лишь управляет внешним процессом, и его прерывание должно быть обработано за Nмкс, при задержке планирования в Mмкс, и N < M (задержка планирования - это время на то, чтобы объявить готовой нить обработчика прерывания, и передать ей управление).

Скорее всего, в маке это какой-нибудь музыкальный инструмент.

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

> Скорее всего, в маке это какой-нибудь музыкальный инструмент.

скорее всего в маке это банальный таймер, который то-же нужно вовремя обрабатывать ;)

// wbr

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

>> Скорее всего, в маке это какой-нибудь музыкальный инструмент.

> скорее всего в маке это банальный таймер

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

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

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

да в сущности любая on-board периферия есть "не внешнее" устройство - USB, UART, PS/2 - но работает один и тот-же код. да и таймер, чес слово, от них ни чем не отличается :) по крайней мере с точки зрения процессора это точно такое же прерывание, как и от PCI-ной аудиокарты.

// wbr

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

> В чем же масштабируемость? Она будет получать выгоду, от того, что вместо 1-ого CPU на этот сервис отведут 16? Очевидно, если вся обработка ведется в пределах 1-ой нити, то нет, а выйти за пределы 1-ой нити вы сами себе не позволили, избавившись от синхронизации :)

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

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

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

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

> Второй аспект немасштабируемости, это высокая алгоритмическая сложность переноса под подобную архитектуру сервисов с других OS,

Я категорически против такого переноса. В силу того, что разработчик будет подсознательно всё сводить к общепринятым приёмам программирования. Поверь, если проектировать сервис или драйвер в концепции синхронных IPC, то код получается гораздо проще, красивее и понятнее.

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

Пожалуйста, обращайся ко мне на ты. А то неудобно как-то себя чувствую.

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

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

> (участливо) Ну что, проблевался? А теперь докажи то, что понаписал.

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

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

> А теперь представь, что отправителей таких сообщений в системе множество, другом конце команды IPC сидит не один обработчик твоих сообщений, а опять же множество, и при этом твоё сообщение будет требовать 100 дней на обработку (ну оно и час может требовать и минуту - всё равно это непомерно долго для проца висеть на вызове команды IPC)

Какое длинное предложение :) Поскольку речь уже не идёт о прерываниях, то вышеописанная ситуация вполне возможна. Вот мы и подошли к самому интересному.

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

Ну а если, в силу каких либо обстоятельств, обработка сообщения требует 100 дней, то да, все источники сообщения будкт непомерно долго висеть на вызове. Но что же будет, если в этом случае использовать асинхронные IPC? А будет то, что они забьют всю память и будут тоже висеть или отвалят по ошибке (зависит от реализации). Или разработчику придётся изобретать велосипед, дабы вручную синхронизировать передачу сообщений.

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

Так что не так старшен чёрт, как его малютка. :)

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

> Это вопрос к Эпплу. Допустим, что устройство всего лишь управляет внешним процессом, и его прерывание должно быть обработано за Nмкс, при задержке планирования в Mмкс, и N < M (задержка планирования - это время на то, чтобы объявить готовой нить обработчика прерывания, и передать ей управление).

> Скорее всего, в маке это какой-нибудь музыкальный инструмент.

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

Во первых, ждём следующее поколение микропроцессоров, которые будут использовать аппаратную реализацию прерываний через IPC. На случай, если какому либо устройству не хватает скорости обработки прерываний по вышеописанному методу. :)

Во вторых, не так уж и много в этом мире устройств, прерывания от которых не успеет обработать PIII 600 Мгц, используя IPC.

В третьих, L4 очень хорошо диспетчеризирует прерывания в события. События от прерываний по-любому имеют приоритет над любыми обычными событиями.

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

> скорее всего в маке это банальный таймер, который то-же нужно вовремя обрабатывать ;)

Кстати, о таймерах. В L4 в качестве таймера используется... IPC. Просто задаётся время ожидания события и если события не произошло, то происходит обрыв. Например, для реализации задержки, достаточно ждать событие от самого себя. Тоже никаких прерываний. Просто ожидания события. Синхронного события.

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

>> Скорее всего, в маке это какой-нибудь музыкальный инструмент.

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

Эх... последний раз пытаюсь объяснить: речь идет о _времени реакции_, а не о частоте процессора. Чтобы тебе было понятнее: "громадный запас" по частоте процессора над частотой слышимых звуков имела уже PC/XT на 8086/4.88МГц.

> Во первых, ждём следующее поколение микропроцессоров, которые будут использовать аппаратную реализацию прерываний через IPC

Ну разве что это поколение разработаешь ты лично. Hint: первые процессоры с аппаратной поддержкой микроядерных IPC появились 20 лет назад. Примерно тогда же они исчезли.

> не так уж и много в этом мире устройств, прерывания от которых не успеет обработать PIII 600 Мгц, используя IPC.

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

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

>> скорее всего в маке это банальный таймер, который то-же нужно вовремя обрабатывать ;)

> Кстати, о таймерах. В L4 в качестве таймера используется... IPC. Просто задаётся время ожидания события и если события не произошло, то происходит обрыв. [...] Тоже никаких прерываний.

Передавай привет знакомым эльфам.

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

> Кстати, о таймерах. В L4 в качестве таймера используется... IPC. Просто задаётся время ожидания события и если события не произошло, то происходит обрыв. Например, для реализации задержки, достаточно ждать событие от самого себя. Тоже никаких прерываний. Просто ожидания события. Синхронного события.

все - или почти все - что вы описываете было успешно реализовано и использовано по всему миру в QNX4 ещё 15 лет назад ;)

// wbr

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

>> В чем же масштабируемость? Она будет получать выгоду, от того, что вместо 1-ого CPU на этот сервис отведут 16? Очевидно, если вся обработка ведется в пределах 1-ой нити, то нет, а выйти за пределы 1-ой нити вы сами себе не позволили, избавившись от синхронизации :)

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

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

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

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

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

>> Второй аспект немасштабируемости, это высокая алгоритмическая сложность переноса под подобную архитектуру сервисов с других OS,

> Я категорически против такого переноса. В силу того, что разработчик будет подсознательно всё сводить к общепринятым приёмам программирования. Поверь, если проектировать сервис или драйвер в концепции синхронных IPC, то код получается гораздо проще, красивее и понятнее.

Похоже на агитацию за ФП ;) В принципе нечто общее тут есть, но драйвера часто портируют с других систем, а не переносят, так что преимущества у "традиционной" очень немалые

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

Ну так вот, файловая система (много разных: FAT, extX, ZFS, xfs, и куча еще), сетевой стек, в том числе TCP протокол, у которого и так конечных автоматов хватает, стек драйверов устройств, собственно драйвера сложных устройств: сложных сервисов в системе каждый второй, так что умом поехать можно :)

> Пожалуйста, обращайся ко мне на ты. А то неудобно как-то себя чувствую.

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

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

>Если обработка сообщения требует больше 100 дней, то это неправильно спроектированная система.

Не, не больше. Ровно 100 дней :-) Я же сразу объяснил почему такая цифра взята, а во-вторых вы напрасно ёрничаете, если атомарная транзакция потребует столько времени - то вы хоть обперепроектируйтесь, а выполняться она будет ровно столько, сколько ей надо. Никогда не видели аналитических запросов в базу данных, которые по нескольку дней там живут, что-ли?

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

Смысл использования IPC - это передача сообщений между процессами системы. И всё.

> Ну а если, в силу каких либо обстоятельств, обработка сообщения требует 100 дней, то да, все источники сообщения будкт непомерно долго висеть на вызове. > Но что же будет, если в этом случае использовать асинхронные IPC? А будет то, что они забьют всю память и будут тоже висеть или отвалят по ошибке (зависит от реализации). Или разработчику придётся изобретать велосипед, дабы вручную синхронизировать передачу сообщений. > А синхронные IPC имеют очень хорошее свойство - величина таймаута. Если в течение этого времени не произведе передача сообщения, то происходит его обрыв с соответствующим кодом ошибки.

Только вот беда, что эти красивые синхронные процессы будут висеть 100 дней в ожидании ответа. Чем это лучше чем "висящие" сообщения?

> Так что не так старшен чёрт, как его малютка. :)

Вот чувствуется, что вам в школе уже начали преподавать основы православной культуры.

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

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

>> (участливо) Ну что, проблевался? А теперь докажи то, что понаписал.

> Хорошо. Зачем обрабатывать сообщения одного типа в нескольких нитях, если их можно обрабатывать в одной нити?

Ну, например, что бы можно было в процессе работы программы добавить в pset на котором она исполняется ещё один процессор. И это будет иметь смысл даже в те моменты, когда в pset присутствует только один cpu :-)

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

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

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.