Програмне забезпечення блокування (локауту)

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

Критичні секції на рівні ядра ред.

У більшості багатопроцесорних системах, кожен процесор планує і сам контролює, тому немає процесора "керівника",[1] і структур даних ядра для спільного використання; розділи коду що доступні до загальних структур даних є критичні секції. Такий дизайн зроблений, щоб поліпшити масштабування, надійність і модульність.[1]

Прикладом такої структури даних ядра є стан процесу і канали зв'язку. «Конфлікт» відбувається тоді, коли більш ніж один процесор намагається отримати доступ до одного ресурсу (частини пам'яті) одночасно. Для запобігання критичних прогонів і неузгодженості, тільки один процесор (CPU) в даний момент часу має право доступу до конкретної структури даних (частини пам'яті), в той час доступ іншим процесорам є заблокованим, вони очікують в режимі готовності.[2]

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

Аналітичні дослідження ред.

Беручи як параметри середній інтервал часу, витраченого процесором в критичних секціях на рівні ядра (L, для часу в заблокованому стані), а середній інтервал часу, витраченого процесором в задачах за межами критичних секцій (Е), відношення L/Е має вирішальну роль в оцінці програмного забезпечення блокування (локауту).

Типові значення для діапазону L / E від 0,01 до 0,1.[3] В системі з L / E ставлення 0,05, наприклад, при наявності 15 процесорів, очікується, що в середньому 1 CPU завжди буде простоювати,[3] з 21 процесорами, 2,8 простоюватиме;[4] з 40 процесорами, 19 будуть простоювати; з 41 процесорами, 20 буде простоювати. Тому додавання більше 40 процесорів в цій системі було б марно. У загальному випадку, для кожного L / значення Е, існує порогове значення для максимальної кількості корисних процесорів.

Пом'якшення блокування програмного забезпечення ред.

Для того, щоб зменшити деградацію продуктивності програмного забезпечення локауту до резонних рівнів (L / E від 0,05 до 0,1), ядро і / або операційна система повинна бути спроектована відповідним чином. Концептуально, найбільш правильним рішенням є розкладання кожної структури даних ядра на невеликі незалежні підструктури, маючи короткий час розробки. Це дозволяє більш ніж одному процесору отримати доступ до вхідної структури даних.

Багато однопроцесорних систем з ієрархічними доменами захисту витрачають до 50% часу виконання в "режимі супервізора" операцій. Якщо такі системи були пристосовані для багатопроцесорної обробки, встановивши блокування будь-якого доступу до “стану супервізора”, L/E буде більшим ніж 1.

Див. також ред.

  • Закон Амдала
  • Залежність проблем в Суперскалярних архітектурах
  • Управління паралелізмом і механізми управління паралелізмом
  • Розділ (комп’ютерні науки)
  • Серіалізація

Примітки ред.

  1. а б Madnick 1968, p.19
  2. Saltzer, Jerome Traffic control in a multiplexed computer system MIT Project MAC MAC-TR-30 June 1966
  3. а б Madnick 1968, p.20
  4. Raynor 76, p.62

Список літератури ред.

  • Madnick, Стюарт Елліот [1] (1968) Multi-процесор програмного забезпечення блокування [2] Праці 1968 23 ACM національної конференції, стор 19 - 24.
  • М. Дюбуа, Ф. Бріггс часу виконання ефективність паралельних асинхронних алгоритмів IEEE Transactions на комп'ютерах, листопад 1991 р. (Тобто 40, № 11) стор. 1260-1266
  • Ренді Дж Рейнор, Джон М. Гвінн, Jr.Minimization супервайзера конфлікту для багатопроцесорних комп'ютерних систем ACM SIGSIM Simulation Digest. Том 7, випуск 4 (липень 1976 р.) . С. 61 - 69

Подальше читання ред.

  • Rodgers, Девід П. (1985) Покращення в багатопроцесорної системі проектування зміст архіву ACM SIGARCH Архітектура комп'ютера Новини том 13, випуск 3 (червень 1985) Спеціальний випуск: Праці 12-го щорічного Міжнародного симпозіуму з комп'ютерної архітектури (ISCA '85) Сторінки : 225 - 231 Рік видання: 1985 ISSN 0163-5964. Також опубліковано в Міжнародному симпозіумі з комп'ютерної архітектури, Праці 12-го щорічного міжнародного симпозіуму з питань комп'ютерної архітектури, 1985, Бостон, Массачусетс, США

Зовнішні посилання ред.

  • J. Cordsen, W. Schroder-Preikschat На шляху до масштабованої архітектури ядра [3] Матеріали осінньої технічної конференції тисячі дев'ятсот дев'яносто дві Openforum. стр. 15 {33, Утрехт, Нідерланди 23 листопада {27, 1992.