Теми рефератів
> Реферати > Курсові роботи > Звіти з практики > Курсові проекти > Питання та відповіді > Ессе > Доклади > Учбові матеріали > Контрольні роботи > Методички > Лекції > Твори > Підручники > Статті Контакти
Реферати, твори, дипломи, практика » Статьи » Механізми синхронізації і взаємодії процесів і потоків

Реферат Механізми синхронізації і взаємодії процесів і потоків





на вхідний порт. Всі процеси мають наступну структуру

begin wait until condition; modify data; end Програма ділиться на дві основні частини. Спочатку перевіряються умови, а потім проводяться операції над даними. Процедура перевірки умови не змінює даних і тому не вимагає будь-якої спеціальної захисту доступу.

Однак доступ до даних для модифікації повинен бути координований між процесами. Якщо використовувати семафори, то їх потрібно два: один - для контролю доступу в захищену область з даними, а інший - для індикації зміни загальних даних і, відповідно, необхідності повторної перевірки умов. Застосування першого семафора просто, а для другого необхідно стежити за числом чекаючих процесів і забезпечити, що при зміні умови очікують процеси будуть активізовані з метою його перевірки, тобто генерацію сигналів семафора, число яких дорівнює числу чекаючих процесів. Це рішення незадовільно через великої витрати машинного часу на численні перевірки, при цьому в програмі досить легко помилитися.

Для вирішення цієї проблеми була введена нова змінна синхронізації event (подія), з якою пов'язані операції await (чекати) і cause (викликати). Процес, який виконав операцію await (event), залишається в стані очікування, поки значення змінної event не зміниться. Ця зміна контролюється за допомогою операції cause . При настанні події, тобто виконанні операції cause (event), звільняються всі очікують його процеси, у той час як у випадку семафора звільняється лише один процес.

Операції з подіями можна реалізувати або за допомогою двійковій змінної, або за допомогою лічильника, при цьому основні принципи залишаються однаковими. Дієслово to await має значення не тільки чекати raquo ;, а й предстояти raquo ;, тобто конструкцію await (А) можна трактувати, як належить подія А raquo ;. Дієслово to cause означає бути причиною raquo ;, спонукальним мотивом, викликати що-небудь raquo ;. Конструкція cause (А) інтерпретується як викликати подія А (в літературі і в операційних системах іноді використовуються й інші назви).

На противагу семафора, змінну події не можна використовувати для захисту ресурсу від конкуруючого доступу декількох процесів, оскільки за визначенням вона звільняє всі очікують процеси. Вищенаведена проблема вирішується за допомогою змінної події і семафора, якщо всі програми мають такий вигляд var mutex: semaphore ; change: event ; begin while not condition do await (change); wait (mutex); (* Обробка загальних змінних *) signal (mutex); cause (change); end ; При кожній зміні змінної event всі процеси перевіряють condition, і тільки ті з них, для яких condition виконано, можуть продовжуватися.

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

взаємовиключення

Об'єкти-взаємовиключення (м'ютекси, mutex - від MUTual EXclusion) дозволяють координувати взаємне виключення доступу до ресурсу,. Сигнальний стан об'єкта (тобто стан встановлений ) відповідає моменту часу, коли об'єкт не належить жодній нитки і його можна захопити raquo ;. І навпаки, стан скинутий (Не сигнальне) відповідає моменту, коли яка-небудь нитка вже володіє цим об'єктом. Доступ до об'єкта дозволяється, коли нитка, що володіє об'єктом, звільнить його. синхронізація потік процес семафор

Дві (або більше) нитки можуть створити мьютекс з одним і тим же ім'ям, викликавши функцію CreateMutex. Перша нитка дійсно створює мьютекс, а наступні - отримують дескриптор вже існуючого об'єкта. Це дає можливість декільком ниткам отримати дескриптор одного і того ж мьютекса, звільняючи програміста від необхідності піклуватися про те, хто насправді створює мьютекс. Якщо використовується такий підхід, бажано встановити прапор bInitialOwner в FALSE, інакше виникнуть певні труднощі при визначенні дійсного творця мьютекса. Кілька ниток можуть отримати дескр...


Назад | сторінка 5 з 6 | Наступна сторінка





Схожі реферати:

  • Реферат на тему: Коли працювати можна менше ...
  • Реферат на тему: Новокаїнові блокади регіонального дії, тобто безпосередньо діють на патолог ...
  • Реферат на тему: Основні технологічні процеси та операції при виробництві хліба
  • Реферат на тему: Гнучкий режим робочого часу та умови його ефективного застосування
  • Реферат на тему: Механізми синхронізації і взаємодії процесів і потоків