колективні ресурси
Уявіть собі пасажирський авіалайнер в польоті, а в ньому такий поділяли всі ресурс, як туалетна кімната. Творці літака передбачали, що тільки одна персона може займати цю кімнату. Перший, хто її зайняв, закриває (lock) доступ до пий для всіх інших. Наступний пасажир, який бажає скористатися цим ресурсом, може або терпляче чекати звільнення, або після закінчення якогось часу (time out) повернутися на своє сидіння і продовжувати займатися тим, чим він був зайнятий до цієї події. Рішення про те, що вибрати і як довго чекати, приймає пасажир. Блокування ресурсу породжує неефективне проведення часу другого пасажира як очікує черги, так і обрав іншу тактику.
Повертаючись до багатопотокових процесів, відзначимо, що якщо не блокувати ресурс, то стає можливим пошкодження даних. Уявіть, що один потік процесу проходить по записах бази даних, підвищуючи зарплату кожному співробітнику на 10%, а інший потік в цей же час змінює поштові індекси в зв'язку з введенням нового стандарту. Погодьтеся з тим, що розумно поєднати ці дві роботи в одному процесі з метою підвищення продуктивності. Що може статися, якщо не блокувати доступ до запису при її модифікації? Перший потік прочитав запис (все її поля), і зайнятий обчисленням підвищення (припустимо, з $ 80. 000 до $ 85 000). В цей час другий потік Новомосковскет цю ж запис з метою зміни поштового індексу. У цій ситуації може відбутися наступне: перший потік зберігає змінену запис з новим значенням зарплати, а другий, повертаючи запис зі зміненим індексом, реставрує значення зарплати і даний співробітник залишиться без підвищення. Це відбувається через те, що обидва потоку не можуть звернутися до частини запису і тому працюють з усією записом, хоча модифікують лише окремі її поля.