Теорія операційної системи

:: Меню ::

Головна
Представлення даних в обчислювальних системах
Машинні мови
Завантаження програм
Управління оперативною пам'яттю
Сегментна і сторінкова віртуальна пам'ять
Комп'ютер і зовнішні події
Паралелізм з точки зору програміста
Реалізація багатозадачності на однопроцесорних комп'ютерах  
Зовнішні пристрої
Драйвери зовнішніх пристроїв
Файлові системи
Безпека
Огляд архітектури сучасних ОС

:: Друзі ::

Карта сайту
 

:: Статистика ::

 

 

 

 

 

 

Монітори і сервери транзакцій

 

Захват ділянок файлу теоретично дозволяє реалізувати будь-яку необхідну структуру того, що взаємовиключає для процесів, що працюють з цим файлом. Проте, практично, при роботі з файлом великої кількості ниток (наприклад, розрахованої на багато користувачів системи управління базами даних), різні нитки часто виявляються вимушені чекати один одного, що приводить до різкого збільшення часу реакції системи. З цим явищем добре знайомі розробники і користувачі файлових СУБД, таких, як Foxpro або dbase IV.
В разі СУБД рішення полягає в створенні сервера БД, або сервера транзакцій який замість примітивів захвату ділянок файлів або таблиць надає користувачам поняття транзакції.
Якщо призначена для користувача сесія оголосила початок транзакції, зміни, які вона вносить до таблиць, безпосередньо в таблицях не відбиваються, і інші сесії, які звертаються до залучених в транзакцію даним, набувають їх вихідних значень. Завершивши модифікацію, призначена для користувача сесія оголошує завершення транзакції. Транзакція може завершитися як виконанням (commit) так і відкотом (rollback).
В разі відкоту змінені дані просто ігноруються. У разі ж виконання сервер вносить зміни до таблиць, проте під час змін він все одно надає іншим ниткам дані в тому достатку, в якому вони були до початку транзакції. Такий підхід збільшує потреби в оперативній і дисковій пам'яті (всі дані, змінні в ході транзакції, повинні зберігатися мінімум двічі: у зміненому і в початковому видах), але забезпечує різке скорочення часу реакції і певне спрощення кодування: програміст тепер не повинен явно перераховувати всі дані, які йому треба заблокувати в ході транзакції. Крім того, Подвійне зберігання даних дозволяє відновити або результат транзакції, або достаток даних до її початку, після збою системи.
Сучасними серверами СУБД є складні програмні Комплекси, які, окрім власне "розв'язки" транзакцій надають складні сервіси оптимізації запитів, індексації і кешування Даних. Та і точний опис поняття транзакції в сучасних мовах запитів до реляційних СУБД (SQL, RPG і ін.) дещо складніше прі-веденного вище. Проте детальне обговорення цього питання відвело б нас Далеко убік від теми книги. Читачеві, що цікавиться цією темою, Можна порекомендувати книги [Дейт 1999, Бобровськи 1998].
Аналогічний серверам транзакцій підхід нерідко використовується і в простіших випадках межпроцессного взаємодії. З ресурсом, що розділяється, асоціюється спеціальна нитка, звана монітором ресурсу. Остальни нитки не можуть звертатися до ресурсу безпосередньо і взаємодіють лише з монітором. Монітор може надавати ниткам-клієнтам несуперечливі достатки контрольованого ним ресурсу (необов'язково співпадаючі з поточним достатком ресурсу) і встановлювати черговість запитів на модифікацію.
Навіть при досить простий стратегії управління ресурсом, монітор корисний тим, що приховує (інкапсулює) структуру і особливості реалізації ресурсу, що розділяється, від клієнтських ниток. Типовий приклад моніторного процесу — драйвер зовнішнього пристрою в багатозадачних ОС.

 

:: Реклама ::

 

:: Посилання ::


 

 

 


Copyright © Kivik, 2017