Редактирование: Параллельная Обработка Данных, 10 лекция (от 06 ноября)

Материал из eSyr's wiki.

Перейти к: навигация, поиск

Внимание: Вы не представились системе. Ваш IP-адрес будет записан в историю изменений этой страницы.

Правка может быть отменена. Пожалуйста, просмотрите сравнение версий, чтобы убедиться, что это именно те изменения, которые вас интересуют, и нажмите «Записать страницу», чтобы изменения вступили в силу.

Текущая версия Ваш текст
Строка 1: Строка 1:
-
[[Параллельная Обработка Данных, 09 лекция (от 30 октября)|Предыдущая лекция]] | [[Параллельная Обработка Данных, 11 лекция (от 13 ноября)|Следующая лекция]]
+
Закончили архитектуру пар выч систем.
-
 
+
-
Закончили архитектуру параллельных вычислительных систем.
+
Для классов были выписаны сложности.
Для классов были выписаны сложности.
-
Вторая тема — Технологии параллельного программирования.
+
Вторая тема -- Технологии параллельного программирования.
-
Программирование на ассемблере уходит в прошлое. Нужен посредник, который записывает методы на языке понятном и нам и машине.
+
Програмирование на асме уходит в рошлое. Нужен посредник, который записывает методы на языке понятном и нам и машине.
-
== Технологии параллельного программирования ==
+
==Технологиии параллельного пограммирования==
-
Задача — Метод — Алгоритм — Технология программирования — Программа — Компилятор — Компьютер
+
Задача--
 +
Метод--
 +
Алгоритм -- Технлогия программирования -- Программа -- Компилятор -- Компьютер
-
ТП — центральная часть. Речь пойдет о параллельных ТП.
+
ТП - центральная часть. Речь пойдет о тп параллельных.
 +
На всей цепочке не долэжно быть ни одного узкого места, в том числе и в технологиях. Технологии должны эффективно выражать метод и эффективно отображать их на разные классы компов. Иногда помогает то, что уже реализовано в архитектуре(супер склярность), но без спец технологий не обойтись. Для того чтобы достчиь цели можно выбрать и массу обходных путей -- сразу с яву на комп(например при использовании какого-нибудь мощного пакета).Вообще,в озможен почти любой обходной путь через основные понятия.
 +
Вообще есть три критерия для тп:
 +
#эффективность. Допускает ои она создание эф программ?
 +
#переносимость. Хочется.ю чтобы программа не была привязана к конкретному компьютеру
 +
#продуктивность. Работы прораммиста.
 +
Любая технология это компромисс между этими критериями. С точки зрения этих критереев будем оценивать технологии
 +
Когда говорим про тпп имеется ввиду целый набор подходов, которыми можно ользоваться:
 +
*Использование традиционных языков программирования. Паскаль, фортран. Предполагается, что комп с парал арх. Кто-то должен определить параллельную струкутуру. Это нагрузка ложиться нак омпилятор. Надежда на умный компилятор, как показыввает история -- пустая.В любом случае требуется вмешательство. Так что, как бы ни был удобен этот путь(столько всего написано), но неээфективен.
 +
*спец комментарии. Не влияют на суть программы, там указываются доп сведения, упрощающие жизнь компилятору. Чутьчуть сдвигаемся в торону эффективности, остаемся в рамках прежней программной инфраструктуры(такую прорамму можно скормить и не поддерживающему спецкоменты компилеру). Это часто использовали на векторных компах. В них самое главное было распознать внутренние циклы без зависимостей. Именно эта доп информация и была наиболее часто используемым видом комментариев.
 +
*Введение доп конструкций в традициионые языки. Была иллюзия, что добавим несколько новых конструкций, человку нужно будет немножко поменять и все станет параллельно. Пример HPF -- через 7-8 лет осознали, что страдает эффективность. MPC - поззволяет прораммировать для неоднородной сети компьютеров.Большие проблемы с переносимостью -- без спецефичных компиляторов для платформы не будет параллельных программ.
 +
*Новые языки. Occam, Sisal. Опять проблемы с переносимостью. Появление любых новых стандартов, вовлечение в свою веру, привлечение людей -- это большие сложности В ипмебыл создан язык НОРМА - для обработки сеточных функций. Хорошо с эффективностью и продуктивностью, плохо с переносимостью, Речи о том чтобы использовать везде к сожалению не идет.
-
Во всей цепочке не должно быть ни одного узкого места, в том числе и в технологиях. Технологии должны эффективно выражать метод и эффективно отображать их на разные классы компов. Иногда помогает то, что уже реализовано в архитектуре(суперскалярность), но без спец технологий не обойтись. Для того чтобы достичь цели можно выбрать и массу обходных путей — сразу с яву на комп (например, при использовании какого-нибудь мощного пакета). На самом деле возможен почти любой обходной путь через основные понятия. Вообще есть три критерия для ТП:
+
Сейчас наиболле распространненая арх - компы с распр памятью. Общение -- передачей сообщений. Появилось много библиотек передачи сообщений.
-
# Эффективность. Допускает ли она создание эффективных программ?
+
*Библиотеки передачи сообщений. PVM, MPI, Shmem. За основу беруться традиционные программы. На сегодняшнитй день 95% процентов прорамм -- это наполовину с, наполовину фортран.
-
# Переносимость. Хочется, чтобы программа не была привязана к конкретному компьютеру
+
*параллельные предмнтные библиотеки. Хорошие пакеты по линейке, преобр фурье, обработки изображений. Обвязка на обычном языке, а весь паралеллизм в спец библиотеке, реализованной специалистами, грамотно распралеллеными. ПРимеры -- Scalapack - основные функции линала для компов с распр памятью.FFTW - преобразования фурье, часто используется, и многие другие. Подход удачный, часто используется.
-
# Продуктивность. Работы программиста.
+
*Специализированные комплексы программ. Средство самого выского уровня, чел формулирует задачу в терминах предметной области, все этапы за программиста сделают. Maxima, ANSYS GAMESS, Flow Vision. Это самый идеальный вариант, если можно этим подходом решить задачу -- то так и надо делать.
-
Любая технология — это компромисс между этими критериями. С точки зрения этих критериев мы и будем оценивать технологии. Когда говорим про ТП, имеется ввиду целый набор подходов, которыми можно пользоваться:
+
Базовый вопрос - дали систему из 1000 процов. А как себе представить себе функционирование программы, анд которой одновременно работают 1000 процессоров. Вопрос о модели о конца не решен, пока есть два подхода
-
* Использование традиционных языков программирования. Паскаль, Фортран. Предполагается, что компьютеры с параллельной архитектурой. Кто-то должен выявить параллельную структуру. Это нагрузка ложиться на компилятор. Надежда на умный компилятор, как показывает история — пустая. В любом случае требуется вмешательство. Так что, как бы ни был удобен этот путь (столько всего написано), он неэффективен.
+
*SPMD(Single program Multiple Data). Берется один код программы и все процессоры работают согласно одной и той же программе, но каждый процесс работает над своими данными. Как этого добиться? В любом случае в тп предусматривается средство самоопределение роцесса. пусть это функция MyID. Оно взвращает униек номер приписанный данному процессору. Как разделить работу? Очен просто --- ид == работе с роцессором номер ид.
-
* Специальные комментарии. Не влияют на суть программы, там указываются дополнительные сведения, упрощающие жизнь компилятору. Чуть-чуть сдвигаемся в сторону эффективности, остаемся в рамках прежней программной инфраструктуры (такую программу можно скормить и не поддерживающему специальные комментарии компилятору). Это часто использовали на векторных компьютерах. В них самым главным было распознать внутренние циклы без зависимостей. Именно эта дополнительная информация и была наиболее часто используемым видом комментариев.
+
*Мастер/Рбочие -- разбиение всего множествоа процессов параллеьной программы на мастера(распределяюещего ресурсы) и подчиненных. Подчиенные как правило работают по одномк =у тексту прораммы, мастр по собственной. Master/Slaves -- запретили по соображением политкорректности.
-
* Введение дополнительных конструкций в традиционные языки. Была иллюзия, что добавим несколько новых конструкций, человеку нужно будет немножко поменять, и всё станет параллельно. Пример — HPF. Где-то через 7-8 лет осознали, что страдает эффективность. MPC — позволяет программировать для неоднородной сети компьютеров. Большие проблемы с переносимостью — без спецефичных компиляторов для платформы не будет параллельных программ.
+
-
* Новые языки. Occam, Sisal. Опять проблемы с переносимостью. Появление любых новых стандартов, вовлечение в свою веру, привлечение людей — это большие сложности. В ипме был создан язык НОРМА — для обработки сеточных функций. Хорошо с эффективностью и продуктивностью, плохо с переносимостью. Речи о том, чтобы использовать везде, к сожалению не идет.
+
-
 
+
-
Сейчас наиболее распространенная архитектура — компы с распределённой памятью. Сообщение компов внутри такой сети при помощи передачей сообщений. Появилось много библиотек передачи сообщений.
+
-
* Библиотеки передачи сообщений. PVM, MPI, Shmem. За основу берутся традиционные программы. На сегодняшний день 95 % процентов программ — это наполовину с, наполовину фортран.
+
-
* параллельные предметные библиотеки. Хорошие пакеты по линейке, преобразование Фурье, обработки изображений. Обвязка на обычном языке, а весь параллелизм в спец библиотеке, реализованной специалистами, грамотно распараллеленными. Примеры — Scalapack — основные функции ЛинАла для компов с распределённой памятью. FFTW — преобразования Фурье, часто используется, и многие другие. Подход удачный, часто применяется.
+
-
* Специализированные комплексы программ. Средство самого высокого уровня, человек формулирует задачу в терминах предметной области, все этапы за программиста сделают. Maxima, ANSYS GAMESS, Flow Vision. Это самый идеальный вариант, если можно этим подходом решить задачу — то так и надо делать.
+
-
 
+
-
Базовый вопрос — дали систему из 1000 процов. А как себе представить себе функционирование программы, над которой одновременно работают 1000 процессоров? Вопрос до модели о конца не решен, пока есть два подхода
+
-
* SPMD(Single program Multiple Data). Берется один код программы и все процессоры работают согласно одной и той же программе, но каждый процесс работает над своими данными. Как этого добиться? В любом случае в ТП предусматривается средство самоопределение процесса. пусть это функция MyID. Она возвращает уникальный номер, приписанный данному процессору. Как разделить работу? Очень просто — ид == работе с процессором номер ид.
+
-
* Мастер/Рабочие — разбиение всего множества процессов параллельной программы на мастера (распределяющего ресурсы) и подчиненных. Подчиненные, как правило, работают по одному тексту прораммы, а мастер - по другому. Master/Slaves — запретили по соображением политкорректности.
+
Перейдем к детальному рассмотрению MPI.
Перейдем к детальному рассмотрению MPI.
-
 
+
==MPI==
-
== MPI ==
+
Начало 90 годов. Аббревиатура от Message Passing Interace. Ориентирована на компы с распр памятью, в которых роцессы общаются с помощью передачи сообщений. Полный вариант стандарта -- более 100 функций. Разберем основные идеи.
-
Начало 90 годов. Аббревиатура от Message Passing Interace. Ориентирована на компы с распр. памятью, в которых процессы общаются с помощью передачи сообщений. Полный вариант стандарта — более 100 функций. Разберем основные идеи.
+
-
 
+
Стандарт 1.1
Стандарт 1.1
-
До сих пор используется, хотя появился уже 2.0. Пользователи не уверены в том что переход на 2.0 эффективен, и многие юзают 1.1.
+
До сих пор используется, хотя появился уже 2.0. Пользователи не уверены в том что переход н 2.0 эффективен и многие юзают 1.1.
-
МПИ распр в виде библиотек для С и фортрана. Все детали текущей реализации доступны на mpiforum.org. На всех современных платформах есть мпи. Изначально он был ориентирован на Линукс, но уже давно есть поддержка для виндовс, в вин кластер сервер — он выдвинут на первый план.
+
МПИ распр в виде библиотек для с и фортрана. Все детали текущей реализации доступны на mpiforum.org,.На всех современных платформах есть мпи. Изначально он был ориентирован на инукс, но уже давно есть погддержка для виндовс, в вин клстер сервер - он выдвинут на первый план.
Конструкции мпи начинаются с MPI_ .
Конструкции мпи начинаются с MPI_ .
-
# include<mpi.h>
+
#include<mpi.h>
-
Что из себя представляет паралл. MPI программа? Это набор независимых процессов (процесс в терминах юникса, у каждого процесса свое адресное пространство, общей памяти у процессов нет). Предполагается, что породили м штук процессов одновремено, потом завершаются. Нельзя динамически породить паралл. процесс. В мпи2 от этого отошли. В очень большом числе случаев это вполне достаточно, как показывает опыт.
+
Что из себя представляет парл мпи программа -- набор независимых процессов(процесс в терминах юникса, у каждого процесса свое адресное пространство, общей памяти у процессов нет). Предпорлагается что породили м штук процессов одновремено, потом завершаются. Нельзя динамически породить парал процесс.В мпи2 от этого отошли. В очень большом числе случаев это вполне достаточно, как показывает опыт.
-
Введено понятие группы процессов. Для группы выделяется специальное пространство для общения, которое называется коммуникатор. Есть надежда, что общение в нескольких коммуникаторах эффективней, чем в общей куче. Имеется нечто всеобъемлющее — коммуникатор, куда погружены все процессы. Он называется MPI_COMM_WORLD — определен всегда. Каждый паралл. процесс имеет уникальный номер. В каждом коммуникаторе процесс может иметь свой номер. В способе формирования коммуникаторов и групп — полная свобода, они могут полностью вкладываться, частично пересекаться, вовсе не пересекаться.
+
Введено понятие группы процессов. Для группы выделяется специальное пространство для общение, которое называется коммуникатор. Есть надежда, что общение в нескольких коммуникаторах эффективней, чем в общей куче. Имеется нечто всеобъемлющее -- коммуникатор куда погружены все процессы. Он называется MPI_COMM_WORLD -- определен всегда. Каждый пар процесс имеет уникальный номер. В каждом коммуникаторе процесс может иметь свой номер. В способе формирования коммуникаторов и групп - полная свобода, они могут полностью вкладываться,частично пересекаться, вовсе не пересекаться.
-
То, что касается сообщений. Набор однотипных данных, которые передаются от одного процесса к другому. Это содержательная сторона сообщения. Важно, что все данные имеют один и тот же тип, для разнородной инфы требуется спец ритуальный танец. Каждое сообщение имеет тэг (некая доп информация, целое число). Введено понятие производных типов. Пользователь может создавать свои типы и их передавать. Например туда пользователь может внести неоднородность.
+
То, что касается сообщений. Набор однотипных данных, кот передаются от одного процесса к другому. Это содержательная сторона сообщения. Важно, что все данные имеют один и тот же тип, для разнородной инфы требуется спец ритуальный танец. Каждое сообщение имеет тэг(некая доп информация, целое число). Введено понятие производных типов.Пользователь может создавать свои типы и их передавать. Например туда пользователь может внести неоднородность.
-
Не во всех задачах процессы общаются аморфной кучей. Иногда процессы например образовывают кольцо, у каждого ровно два соседа. Есть понятие виртуальная топология, определив которое, можно навести порядок в общении процессов друг с другом. Часто процессы располагают в узлах прямоугольной решетки с/без зацикленности по тору.
+
Не во всех задачах процессы общаются аморфной кучей. Иногда процессы например образовывают кольцо, у каждого ровно два соседа. Есть понятие виртуальная топология, опредлив которое можно навести порядок в общении процессов друг с другом. Часто процессы распологают в узлах прямоугольной решетки с/без зацикленности по тору.
-
Несколько слов о самой технологии. Рассматривать будем на примере с. Основа с эта функция.
+
Несколько слов о самой технлогии. Рассматривать будем на примере с. Основа с эта функция.
-
Любая мпи функция возвращает код. Если вернулось MPI_SUCCESS — всё закончилось нормально. Если же вернулось не это значение — код ошибки можно посмотреть в стандарте.
+
Любая мпи функция возвращает код - MPI_SUCCESS - все закончилось нормально. Если вернулось не это значение -- код ошибки можно посмтореть в стандарте.
-
* Общие функции.
+
*Общие функции.
-
** MPI_Init(int * argc, char *** argv); сколько процессов породилось — указано в аргв. Все остальные действия могут выполняться только поосле того как выполнилась функция мпи инит. Но и выполнить ее можно только один раз.
+
mpi_init(int *argc, char***argv); сколько процессов породилось - указано в аргв. Все остальные действия могут выполняться только поосле того как выполнилась функция мпи инит. Но и выполнить ее можно только один раз.
-
** MPI_Finalize(void) — закончить все мпи процессы.
+
mpi_inalize(void) - закончить все мпи процессы.
-
** MPI_Initialized(int *flag) — запускал ли кто-нибудь уже мпи_инит или нет. Содержательный результат возвращется через флаг
+
mpi_initialized(int *flag) - запускал ли кто-нибудь уже мпи_инит или нет.Содержательный результат возвращется через флаг
-
** MPI_Comm_size(MPI_COMM comm, int *size) — количество параллельных процессоров в данном коммуникаторе.
+
.mpi_comm_size(MPI_COMM comm, int *size) - количество параллельных процессоров в данном коммуникаторе.
-
** MPI_Comm_run(MPI_COMM comm, int *my_id) — коммуникатор и переменная куда будет зписан номер процесса.
+
mpi_comm_run(MPI_COMM comm, int *my_id) -- коммуникатор и переменная куда будет зписан номер процесса.
Осмысленная мпи программа:
Осмысленная мпи программа:
Порождает некторое кол-во процессов, каждый процесс определяет сколько работает рядом с ним и свой номер.
Порождает некторое кол-во процессов, каждый процесс определяет сколько работает рядом с ним и свой номер.
 +
#include <mpi.h>
 +
main(int argc, char * argv[])
 +
{
 +
int size;//щбщее кол-во процессов
 +
int my_id;//номер текущего
 +
mpi_init(&argc, &argv);
 +
// порождение произошло, теперь смотрим сколько вокруг и свой номер
 +
mpi_comm_size(MPI_COMM_WORLD, &size);
 +
mpi_comm_run(MPI_COMM_WORLD, &my_id);
 +
printf("Total: %d \n proc %d", size, my_id);
 +
mpi_finalize();
 +
}
-
#include <mpi.h>
+
Сколько процессов порождается -- указывается через аргв. Напечатано будет столько раз, сколько процессов породилось. Порядок в котором появятся выдачи заранее не определен, он может быть любым. Гарантируется лишь что строка эьто неделимая сущность и она выдается целиком.
-
main(int argc, char * argv[])
+
*Взаимодействие процессов
-
{
+
**Коллективные операции(все процессы воввлечены)
-
int size;//щбщее кол-во процессов
+
**Точка-точка(взаимодействует пара процессов между собой)
-
int my_id;//номер текущего
+
***Синхронные(с блокировкой)
-
MPI_Init(&argc, &argv);
+
MPI_send(void *buf, int count, MPI_Datatype, int dest, int tag, MPI_comm comm) -- буффер сообщения который надо передать, кол-во элементов, тип элементов, номер процесса получателя, тэг, в рамках какого коммуникатора
-
// порождение произошло, теперь смотрим сколько вокруг и свой номер
+
Причем тут синхронность? Она тут трактуется не совсем стандартно. ПОсылающий процесс блокируется до тех пор, пока у него есть опасение испортить отправляемые параметры.Гарантируется, что что бы в отправляющем процессе не стояло после мпи_сенд, оно будет отправлено ровно в том виде в каком было на моент вызова мпи_сенд. Доставка не гарантируется.
-
MPI_Comm_size(MPI_COMM_WORLD, &size);
+
MPI_Recv(void *buf, int count, MPI_Datatype, int dest, int tag, MPI_comm comm, MPI_Status * status) -- статус описывает статус принимаемого сообщения. Возврат произойдет только когда в буффер запишутся все каунт элементов принмаемого сообщения.
-
MPI_Comm_run(MPI_COMM_WORLD, &my_id);
+
Вся система построена на том, что есть два процесса -- один посылает, а другой принимает.
-
printf("Total: %d \n proc %d", size, my_id);
+
Несколько общих замечаний.
-
MPI_Finalize();
+
Предположим, есть процесс А и процесс Б. В некоторый момент процесс А посылает Б два сообщения. Процесс Б их может принять. И оба сообщения идут с одним и тем же тэгом. Есть ли гарантия того что сообщения придут в определенном порядке? Да. Если от одного и того же процесса ушли два сообщения, то первым приде то, кторое первым было отправлено. Но вот если А и С отправляют что-то Б, то чьё сообщение придет первым -- неопределено
-
}
+
Есть константа MPI_ANYSOURCE - если ее поставить в ресв то сообщения будут ждаться от любого процесса. Аналогично MPI_ANYTAG.
-
 
+
Справедливости в обслуживании процессов нет. Если Б зкидывает А сообщениями в цикле, то еденичное сообщение из С в А может и не пробиться.
-
Сколько процессов порождается — указывается через argv. Напечатано будет столько раз, сколько процессов породилось. Порядок, в котором появляются выдачи, заранее не определен, он может быть любым. Гарантируется лишь что строка — это неделимая сущность и она выдается целиком <!-- на самом деле, тут надо пояснить, кем это гарантируется. Так как неопределённость возникает именно при доступе к устройствам ввода-вывода, то именно в сторону их и надо смотреть. Кроме того, понятно, что это гарантируется тем, что эти операции выполняются последовательно, не определён лишь их порядок (отсюда мораль — как можно меньше дёргать I/O) -->.
+
Принятая семантика синхронных операций может приводить к тупиковым ситуациям.
-
 
+
Есть два процесса, им надо обменяться сообщениями.
-
* Взаимодействие процессов
+
Оба пишут
-
** Коллективные операции(все процессы вовлечены)
+
MPI_Send
-
** Точка-точка(взаимодействует пара процессов между собой)
+
MPI_Recv
-
*** Синхронные(с блокировкой)
+
А сделал сенд Б, аналогично Б сделал сенд А. А дальше у них стоит прием. Оба процесса могут стоять бесконечон долго ожидая завершения мпи_сенд, из за особенности семантики мпи_сенд. Конкретная реализация может ожидать того, что принмающая сторона заберет сообщение. И все друг друга ждут. Эта ситуация описана во всех мануалах, она просто обходится при помощи операций асинхронного взаимодействия. Но к этому надо быть готовыми. Она может проявятьс япо разному -- аналогичный эффет возникает если надо организовать обмен сообщений между соседями в кольце.
-
**** MPI_Send(void * buf, int count, MPI_Datatype, int dest, int tag, MPI_comm comm) — буфер сообщения который надо передать, кол-во элементов, тип элементов, номер процесса получателя, тег, в рамках какого коммуникатора.
+
***Асинхронные(без блокировки)
-
***: Причем тут синхронность? Она тут трактуется не совсем стандартно. Посылающий процесс блокируется до тех пор, пока у него есть опасение испортить отправляемые параметры. Гарантируется, что что бы в отправляющем процессе не стояло после мпи_сенд, оно будет отправлено ровно в том виде в каком было на момент вызова мпи_сенд. Доставка не гарантируется.
+
-
**** MPI_Recv(void * buf, int count, MPI_Datatype, int dest, int tag, MPI_comm comm, MPI_Status * status) — статус описывает статус принимаемого сообщения. Возврат произойдет только когда в буфер запишутся все count элементов принимаемого сообщения.
+
-
***: Вся система построена на том, что есть два процесса — один посылает, а другой принимает.
+
-
***: Несколько общих замечаний.
+
-
***: Предположим, есть процесс А и процесс Б. В некоторый момент процесс А посылает Б два сообщения. Процесс Б их может принять. И оба сообщения идут с одним и тем же тэгом. Есть ли гарантия того что сообщения придут в определенном порядке? Да. Если от одного и того же процесса ушли два сообщения, то первым приде то, которое первым было отправлено. Но вот если А и С отправляют что-то Б, то чьё сообщение придет первым — неопределено
+
-
***: Есть константа MPI_ANYSOURCE — если ее поставить в ресв то сообщения будут ждаться от любого процесса. Аналогично MPI_ANYTAG.
+
-
***: Справедливости в обслуживании процессов нет. Если Б закидывает А сообщениями в цикле, то единичное сообщение из С в А может и не пробиться.
+
-
***: Принятая семантика синхронных операций может приводить к тупиковым ситуациям.
+
-
***: Есть два процесса, им надо обменяться сообщениями.
+
-
***: Оба пишут
+
-
***: MPI_Send
+
-
***: MPI_Recv
+
-
***: А сделал сенд Б, аналогично Б сделал сенд А. А дальше у них стоит прием. Оба процесса могут стоять бесконечно долго ожидая завершения мпи_сенд, из за особенности семантики мпи_сенд. Конкретная реализация может ожидать того, что принимающая сторона заберет сообщение. И все друг друга ждут. Эта ситуация описана во всех мануалах, она просто обходится при помощи операций асинхронного взаимодействия. Но к этому надо быть готовыми. Она может проявляться по-разному — аналогичный эффект возникает если надо организовать обмен сообщений между соседями в кольце.
+
-
*** Асинхронные(без блокировки)
+
-
 
+
-
{{Параллельная Обработка Данных}}
+
-
{{Lection-stub}}
+

Пожалуйста, обратите внимание, что все ваши добавления могут быть отредактированы или удалены другими участниками. Если вы не хотите, чтобы кто-либо изменял ваши тексты, не помещайте их сюда.
Вы также подтверждаете, что являетесь автором вносимых дополнений, или скопировали их из источника, допускающего свободное распространение и изменение своего содержимого (см. eSyr's_wiki:Авторское право).
НЕ РАЗМЕЩАЙТЕ БЕЗ РАЗРЕШЕНИЯ ОХРАНЯЕМЫЕ АВТОРСКИМ ПРАВОМ МАТЕРИАЛЫ!


Отменить | Справка по редактированию (в новом окне)

Шаблоны, использованные на этой странице:

Получено с http://esyr.org/wiki/%D0%9F%D0%B0%D1%80%D0%B0%D0%BB%D0%BB%D0%B5%D0%BB%D1%8C%D0%BD%D0%B0%D1%8F_%D0%9E%D0%B1%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%BA%D0%B0_%D0%94%D0%B0%D0%BD%D0%BD%D1%8B%D1%85%2C_10_%D0%BB%D0%B5%D0%BA%D1%86%D0%B8%D1%8F_%28%D0%BE%D1%82_06_%D0%BD%D0%BE%D1%8F%D0%B1%D1%80%D1%8F%29
Личные инструменты
Разделы