Составители:
Однако, приведенная схема реализации все-таки не соответ-
ствует поставленной задаче, ибо значение count должно быть нулем
в начале каждой интерации, т.е. переменной count нужно присва-
ивать 0 после того, как все процессы подойдут к барьеру, но это
обстоятельство не отражено в упомянутой схеме.
Можно было бы эту проблему решить, введя два счетчи ка,
один из которых уменьшается, а другой возрастает, причем роли
счетчиков меняются при переходе к следующей итерации. Однако,
это ведет к новым трудностям:
1) увеличивать и уменьшать н ужно неделимым образом (зна-
чит, кроме FA нужно иметь неделимую операцию "извлечь и
вычесть" — назовем ее FM);
2) когда процес с приостанавливается, он непрерывно проверя-
ет значение переменной count; поскольку число ожидающих у ба-
рьера процессов доходит до n − 1, то при больших значениях n это
может привести к конфликтам при обращении к памяти (за значе-
нием count). Если же у каждого процесса имеется быстрая память
(кэш), то возникает проблема поддержания когерентности кэшей
(под когерентностью кэшей подразумевается тождественность их
содержания).
Вывод:
рассмотренный здесь способ следует использовать
лишь при малом n.
§11 Управляющие процессы
Пусть имеется массив arrive[1 : n] с нулевыми н ачальными значе-
ниями. Заменим операцию увеличения счетчика count присваи ва-
нием arrive[i] = 1. Глобальным инвариантом служит предикат
count == (arrive[1] + . . . + arrive[n]).
Если элементы массива arrive хранятся в разных строках кэш-
памяти, то конфликтов в памяти п ри обращении к ним не будет, но
вместо неделимого действия
< await (count == n); >
потребуется неделимое действие
< await
(arrive[1] + . . . + arrive[n]) == n
; >,
62
Страницы
- « первая
- ‹ предыдущая
- …
- 59
- 60
- 61
- 62
- 63
- …
- следующая ›
- последняя »
