Підтримка багатопроцесорності у Windows ХР

За умов багатопроцесорної системи планувальник Windows ХР визначає поря­док виконання потоків і процесори, на яких вони мають виконуватися. При цьо­му за замовчуванням підтримують м'яку спорідненість. Крім того, аналогічно до Linux у системі може бути задана жорстка спорідненість на основі маски спорід­неності, а серед процесорів, заданих у масці спорідненості потоку, додатково виби­рають ідеальний процесор (ideal processor). Планувальник планує потік для вико­нання на ідеальному процесорі, якщо він є доступним у цей момент.

Маска спорідненості потоку, номер ідеального процесора і номер процесора, на якому потік виконувався останній раз, містяться в керуючому блоці потоку (KTHREAD), маска спорідненості процесу - у блоці KPR0CESS. Під час створення потоку його маску спорідненості ініціалізують значенням маски спорідненості процесу.

У разі постановки потоку на виконання відбуваються такі дії.

1. Процесором, на якому виконуватиметься потік, планувальник намагається зро­бити ідеальний процесор.

2. Якщо ідеальний процесор недоступний, вибирають процесор, на якому потік виконувався востаннє.

3. Якщо і цей процесор зайнятий, вибирають інший вільний процесор або проце­сор, на якому виконується потік із нижчим пріоритетом.

 

Задання жорсткої спорідненості та ідеального процесора

Жорстка спорідненість може бути задана (маска спорідненості змінена із програми) за допомогою функцій SetProcessAffinityMaskO (для процесу) або SetThreadAffinity-MaskO (для окремого потоку).

DWORD mask_proc - 2: // другий процесор (маска 000...0010) SetProcessAffinityMask(GetCurrentProcess(). &mask_proc)

Для визначення поточного значення маски спорідненості процесу використо­вують функцію GetProcessAffinityMask().

DWORD mask_proc, masksys;

// у масці mask_sys увімкнуто біти для всіх доступних процесорів

GetProcessAffinityMask(GetCurrentProcess(). &mas_kproc. Smasksys): printf("маска процесу: %081x. системна маска: %081х\п". mask_proc. masksys);

 

Ідеальний процесор вибирають випадково під час створення потоку. Щоб зміни­ти його із застосування, потрібно використати функцію SetThreadldeal Processor().

 

SetThreadIdealProcessor(GetCurrentThread(), 1); // другий процесор

 

Підтримка NUMA-систем

Windows ХР, як і Linux, підтримує внутрішнє відображення топології вузлів і ви­користовує його під час планування потоків. Win32 АРІ містить ряд функцій, що дають змогу отримати інформацію про поточну топологію (наприклад, функція GetNumaProcessorNode() повертає номер вузла для заданого процесора). Цю інформа­цію можна застосувати для оптимізації використання локальної пам'яті, наприклад шляхом задання маски спорідненості, що включає всі процесори одного вузла.

 

Принципи розробки розподілених систем

У цьому розділі йтиметься про базові технології розробки розподілених систем. До них належать передавання повідомлень і віддалені виклики процедур (RPC). Передавання повідомлень, а також базові принципи RPC розглянуто в розділі 6. У розділах 20.2.1-20.2.3 висвітлюватимуться особливості застосування RPC для розробки розподілених застосувань.

 

Віддалені виклики процедур

RPC відрізняється від сокетів тим, що в разі використання цієї технології мережа є прозорою для програміста. Ця прозорість виявляється в тому, що код клієнт­ських застосувань і серверних процедур, які взаємодіють за допомогою RPC, пев­ною мірою виглядає так, ніби мережі немає; фактично його не можна відрізнити від коду, котрий використовує локальні процедури. Покажемо, внаслідок чого вдається досягти такої прозорості.

 

Заглушки

Основна ідея, на якій Грунтуються RPC, полягає в тому, що клієнт і сервер по­в'язані не прямо, а через заглушки (stubs) - спеціальні програмні модулі, відпові­дальні за мережну взаємодію. Розглянемо, які заглушки беруть участь у виклику віддаленої процедури.

1. Під час звертання до віддаленої процедури клієнтський процес використовує локальні домовленості про виклик (аналогічні до виклику локальної процедури), але насправді звертається до клієнтської заглушки (client stub), що маршалізує параметри і пересилає їх серверу. Під маршалізацією (marshaling) розуміють упакування даних у формат, придатний для передавання мережею (із мереж-ним порядком байтів тощо), під демаршалізацією (demarshaling) - їхнє зво­ротне перетворення.

2. На сервері дані приймає серверна заглушка (server stub), демаршалізує парамет­ри і викликає віддалену процедуру. Вона також буде викликана із локальними

домовленостями про виклик, її код не має інформації про те, що виклик був

віддаленим. Після цього серверна заглушка маршалізує повернені значення

і передає їх назад клієнтові.

3. На клієнті повернені значення демаршалізує клієнтська заглушка і передає

клієнтському застосуванню аналогічно до даних локальної процедури.

Основною особливістю заглушок є те, що вони мають ті самі інтерфейси, що й відповідні процедури. Клієнтська заглушка виглядає для застосування-клієнта як локальна процедура з одними й тими самими параметрами; серверна заглушка виглядає для віддаленої процедури як локальний клієнт.

 

Мова IDL

Для автоматизації створення заглушок у RPC використовують опис інтерфейсів процедур спеціальною мовою опису інтерфейсів (Interface Definition Language, IDL). Кожну процедуру, яку потрібно викликати віддалено, необхідно описати на IDL, задавши ім'я процедури, кількість і типи параметрів, а також тип повернен­ня. Файл з IDL-кодом, який містить оголошення таких процедур, обробляють IDL-компілятором, що генерує заглушки для клієнта і сервера.

Архітектура віддаленого виклику процедур показана на рис. 20.2.

Є різні реалізації ГОЦ що втілюють загальні принципи цієї мови.

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

2. IDL є декларативною мовою, вона призначена виключно для опису інтерфей­сів (фактично це зводиться до опису заголовків процедур і типів даних). Вико­нуваних операторів у ній немає.

3. Для забезпечення зв'язку між неоднорідними системами в IDL має бути зафік­совано набір базових типів (наприклад, може бути прийнято, що і nt завжди буде завдовжки 4 байти тощо).

4. Параметри процедур в IDL мають режими. Режим параметра визначає напря­мок пересилання відповідних даних. Для вхідних параметрів дані передають від клієнта серверу, для вихідних — від сервера клієнтові, для параметрів змі­шаного режиму - в обидва боки.

 

Використання Sun RPC

Однією із найрозповсюдженіших реалізацій RPC-технології для UNIX-систем є Sun RPC [37, 52]. До її особливостей належить реалізація на основі TCP/IP, не­залежність від відображення даних на клієнті та сервері (за перетворення між ти­пами відповідає бібліотека часу виконання RPC).