Изменения
Новая страница: «Категория:Параллельное программирование * Синхронные системы ** Известно, что любое со…»
[[Категория:Параллельное программирование]]
* Синхронные системы
** Известно, что любое сообщение либо доставляется за некоторое время $C$, либо полностью исчезает
** Тогда можно разбить выполнение алгоритма на фазы длиной $O(C)$: в начале фазы все процессы отправляют сообщения, потом ждут, а в конце знают, что получили все сообщения, которые только могли прийти
* Асинхронные системы
** Время передачи сообщения сверху не ограничено
** Но гарантируется, что если нет отказов, то сообщение рано или поздно дойдёт
** Мы принципиально не можем использовать таймауты, поэтому нельзя смотреть на время даже внутри одного процесса: он либо что-то делает внутри себя, либо ждёт очередного сообщения бесконечно долго.
Асинхронную систему можно на практике попробовать(?) превратить в синхронную при помощи таймаутов: к каждому сообщению прикрепляем wall clock time (которое не может быть идеально синхронизировано в распределённой системе, но на практике хоть как-то можно, сбои не всегда играют против нас) и игнорируем слишком старые сообщения. Надо аккуратно поиграть с определениями и учесть погрешность и потребовать, чтобы часы не расходились, возможно, ещё что-то.
Выберем большой таймаут — будет тормозить, выберем маленький — будут большие потери сообщений.
Если решили задачу для асинхронной системы, то в синхронной будет работать то же самое.
Но, возможно, для синхронной системы существует более эффективный алгоритм.
На практике могут использоваться алгоритмы и для тех, и для других.
* Синхронные системы
** Известно, что любое сообщение либо доставляется за некоторое время $C$, либо полностью исчезает
** Тогда можно разбить выполнение алгоритма на фазы длиной $O(C)$: в начале фазы все процессы отправляют сообщения, потом ждут, а в конце знают, что получили все сообщения, которые только могли прийти
* Асинхронные системы
** Время передачи сообщения сверху не ограничено
** Но гарантируется, что если нет отказов, то сообщение рано или поздно дойдёт
** Мы принципиально не можем использовать таймауты, поэтому нельзя смотреть на время даже внутри одного процесса: он либо что-то делает внутри себя, либо ждёт очередного сообщения бесконечно долго.
Асинхронную систему можно на практике попробовать(?) превратить в синхронную при помощи таймаутов: к каждому сообщению прикрепляем wall clock time (которое не может быть идеально синхронизировано в распределённой системе, но на практике хоть как-то можно, сбои не всегда играют против нас) и игнорируем слишком старые сообщения. Надо аккуратно поиграть с определениями и учесть погрешность и потребовать, чтобы часы не расходились, возможно, ещё что-то.
Выберем большой таймаут — будет тормозить, выберем маленький — будут большие потери сообщений.
Если решили задачу для асинхронной системы, то в синхронной будет работать то же самое.
Но, возможно, для синхронной системы существует более эффективный алгоритм.
На практике могут использоваться алгоритмы и для тех, и для других.
