На теоретичному рівні вони семантично не відрізняються. Ви можете реалізувати mutex за допомогою семафорів або навпаки (див. Тут приклад). На практиці реалізація різна, і вони пропонують дещо різні послуги.
Практична відмінність (з точки зору системних служб, що їх оточують) полягає в тому, що реалізація мютексу спрямована на створення більш легкого механізму синхронізації. У мові, що говорить оракул, мютекси відомі як засувки, а семафори відомі як чекання .
На найнижчому рівні вони використовують якийсь механізм атомного випробування та встановлення . Це зчитує поточне значення місця в пам'яті, обчислює якесь умовне і записує значення в цьому місці в одній інструкції, яку неможливо перервати . Це означає, що ви можете придбати мютекс і перевірити, чи не було у вас когось іншого перед вами.
Типова реалізація mutex має процес або потік, що виконує інструкцію тестування та встановлення та оцінює, чи не встановило щось інше mutex. Ключовим моментом тут є те, що немає взаємодії з планувальником , тому ми не маємо уявлення (і все одно), хто встановив блокування. Тоді ми або відмовляємося від свого часового відрізка і намагаємося його повторно, коли завдання буде переплановано, або виконаємо спін-блокування . Спіновий замок - це такий алгоритм, як:
Count down from 5000:
i. Execute the test-and-set instruction
ii. If the mutex is clear, we have acquired it in the previous instruction
so we can exit the loop
iii. When we get to zero, give up our time slice.
Коли ми закінчимо виконання нашого захищеного коду (відомий як критичний розділ ), ми просто встановимо значення mutex у нуль або будь-що означає «очистити». Якщо декілька завдань намагаються придбати мютекс, то наступне завдання, яке трапляється заплановано після випуску файлу, отримає доступ до ресурсу. Зазвичай ви використовуєте мутекси для керування синхронізованим ресурсом, коли ексклюзивний доступ потрібен лише на дуже короткий проміжок часу, як правило, для оновлення спільної структури даних.
Семафор - це синхронізована структура даних (як правило, використовуючи мютекс), що має кількість та обгортки системних викликів, які взаємодіють із планувальником на трохи більшій глибині, ніж би бібліотеки mutex. Семафори збільшуються та зменшуються та використовуються для блокування завдань, поки щось інше не буде готове. Див. Проблема виробника / споживача для простого прикладу цього. Семафори ініціалізуються на деяке значення - бінарний семафор - це лише особливий випадок, коли семафор ініціалізується до 1. Опублікування семафору призводить до пробудження процесу очікування.
Основний алгоритм семафору виглядає так:
(somewhere in the program startup)
Initialise the semaphore to its start-up value.
Acquiring a semaphore
i. (synchronised) Attempt to decrement the semaphore value
ii. If the value would be less than zero, put the task on the tail of the list of tasks waiting on the semaphore and give up the time slice.
Posting a semaphore
i. (synchronised) Increment the semaphore value
ii. If the value is greater or equal to the amount requested in the post at the front of the queue, take that task off the queue and make it runnable.
iii. Repeat (ii) for all tasks until the posted value is exhausted or there are no more tasks waiting.
У випадку двійкового семафору основною практичною відмінністю між ними є характер системних служб, що оточують фактичну структуру даних.
РЕДАКТУВАННЯ: Як справедливо зазначав Еван, спіллокс сповільнить роботу однієї процесорної машини. Ви б використовували спінлок на мультипроцесорній коробці, оскільки на одному процесорі процес, що містить мутекс, ніколи не скине його під час виконання іншого завдання. Спінлок корисний лише для багатопроцесорних архітектур.