Page 104 - 6571

}

Хоча в програмі 1.14 бар’єрна синхронізація реалізована

таким чином, що конфлікти звернення до пам’яті не виникають,
проте у даного рішення є дві небажані властивості. По-перше,
потрібен додатковий процесор. Синхронізація з активним

очікуванням ефективна, якщо тільки кожен процес виконується
на окремому процесорі, так що процесу Coordinator потрібен
свій власний процесор. Проте, можливо даний процесор
доцільніше було б використовувати для іншого робочого

процесу.
Другий недолік використання керуючого процесу полягає в

тому, що час виконання кожної ітерації процесу Coordinator, і,
отже, кожного екземпляра бар’єрної синхронізації пропорційний
числу процесів Worker. У ітераційних алгоритмах дуже часто всі
робочі процеси мають ідентичний код. Це означає, що якщо

кожен робочий процес виконується на окремому процесорі, то всі
вони підійдуть до бар’єра приблизно в один і той же час. Таким
чином, всі прапорці arrive будуть встановлені практично

одночасно. Однак процес Coordinator перевіряє прапорці в
циклі, по черзі очікуючи, коли буде встановлений кожен із них.

12.3 Бар’єр з об’єднуючим деревом

Обидві проблеми можна вирішити, об’єднавши дії керуючого
і робочих процесів так, щоб кожен робочий процес був одночасно
і керуючим. Організуємо робочі процеси в дерево (рис. 12.1).

Сигнал про те, що процес підійшов до бар’єра (прапорець
arrive[i]), відсилається вгору по дереву, а сигнал про дозвіл
продовжити виконання (прапорець continue[i]) – вниз по
дереву.

103