5. 2 Основні проблеми взаємодії потоків

5. 2. 1 Проблема змагання

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

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

total_amount=total_amount+new_amount;

Виникає запитання: чи можна дати гарантію, що внаслідок роботи із вкладом потік, відповідає кожному користувачу, буде здатний збільшити значення total_amount на потрібну величину?

Насправді цей на перший погляд найпростіший оператор зводиться до послідовності таких дій:

• отримання поточного значення total_amount із глобальної пам’яті;

• збільшення його на new_amount і збереження результату в глобальній пам’яті.

Розглянемо випадок, коли два користувачі А і В спільно користуються одним і тим самим рахунком. На рахунку є 100 грошових одиниць. Користувач А збирається покласти на рахунок 1000, користувач В у цей самий час – 100. Потік Т_А відповідає користувачу А, потік Т_В – користувачу В. Розглянемо таку послідовність подій (варіант 1).

1. Потік Т_А зчитує значення total_amount, рівне 100.

2. Потік Т_В зчитує значення total_amount, теж рівне 100.

3. Потік Т_А збільшує зчитане на кроці 1 значення total_amount на 1000, отримує 1100 і зберігає його у глоальній пам’яті.

4. Потік Т_В збільшує зчитане на кроці 2 значення total_amount на 100, отримує 200 і теж зберігає його у глобальній пам’яті, перезаписуючі те, що зберіг потік Т_А.

У результаті внесок користувача А повністю втрачено.

Тепер розглянемо іншу послідовність подій (варіант 2).

1. Потік Т_А зчитує total_amount, збільшує його на 1000 і записує значення 1100 у глобальну пам’ять.

2. Потік Т_В зчитує total_amount, рівний 1100, збільшує його на 100 і записує значення 1200 у глобальну пам”ять.

У результаті обидва внески зареєстровані успішно.

Як бачимо, результат виконання наведеного раніше найпростішого фрагменту коду залежить від послідовності виконання потоків у системі. Це спричиняє до такого: в одній систуації код може працювати, в іншій – ні, і передбачити появу помилки в загальному випадку неможливо. Таку ситуацію називають станом гонок або змаганням (race condition), що є однією з найбільш важко вловлюваних помилок, з якими зіштовхуються програмісти. Вона практично не піддається налогодженню (оскільки нереально перебрати у налогоджувачі всі можливі комбінації послідовностей виконання потоків, особливо якщо їх багато).

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

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

Ознайомимся із правилами, яких треба дотримуватися, аби створений код відповідав цьому принципу.

Розглянемо основні підходи до розв’язання проблеми змагань.

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

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

У всіх інших випадках потрібно забезпечувати захист змін від впливу інших потоків. Це і є основним завданням синхронізації.

Розглянемо різні підходи до його розв’язання.