Семафор можна підрахувати, в той час як м'ютекс може розраховувати тільки на 1.
Припустимо, що у вас є потік, який приймає з'єднання з клієнтом. Цей потік може одночасно обробляти 10 клієнтів. Потім кожен новий клієнт встановлює семафор, поки він не досягне 10. Коли у семафора є 10 прапорів, ваш потік не братиме нові сполуки
М'ютекс зазвичай використовується для захисту речей. Припустимо, що ваші 10 клієнтів можуть отримати доступ до декількох частин системи. Потім ви можете захистити частина системи за допомогою мьютекса, тому, коли 1 клієнт підключений до цієї підсистемі, ніхто інший не повинен мати доступ. З цією метою ви також можете використовувати Семафор. М'ютекс - це «Взаємний семафор».
На жаль, все пропустили найважливіше відмінність між семафором і м'ютексів; Концепція «власності».
Семафори не мають поняття власності, це означає, що будь-який потік може звільняти семафор (це може призвести до багатьох проблем саме по собі, але може допомогти з «виявленням смерті»). У той час як у мьютекса є концепція власності (тобто Ви можете тільки відпустити м'ютекс, який ви придбали).
Власність неймовірно важлива для безпечного програмування паралельних систем. Я завжди рекомендую використовувати м'ютекси, вважаючи за краще семафор (але є наслідки для продуктивності).
М'ютекси також можуть підтримувати пріоритетне спадкування (що може допомогти у вирішенні проблеми інверсії пріоритету) і рекурсія (виключаючи один тип взаимоблокировки).
Слід також зазначити, що існують «виконавчі» семафори і «лічильники / загальні» семафори. Семафор Java являє собою рахунковий семафор і, таким чином, дозволяє його форматувати зі значенням, більшим одного (тоді як, як зазначено, м'ютекс може мати тільки концептуальне значення одного). Корисність цього вказала на інші посади.
Отже, щоб узагальнити, якщо у вас немає кількох ресурсів для управління, я завжди рекомендую м'ютекс над семафором.
М'ютекс - це в основному взаємне виключення. Тільки один потік може відразу отримати ресурс. Коли один потік отримує ресурс, нікому іншому потоку заборонено купувати ресурс до тих пір, поки потік, який володіє ресурсами, не буде звільнений. Всі потоки, які очікують придбання ресурсу, будуть заблоковані.
Семафор використовується для управління кількістю виконуваних потоків. Буде встановлено фіксований набір ресурсів. Рахунок ресурсів буде зменшуватися кожного разу, коли потік володіє тим же. Коли рахунок семафора досягає 0, ніякі інші потоки не можуть отримати ресурс. Потоки блокуються доти, поки інші потоки не будуть мати ресурси.
Коротше кажучи, основна відмінність полягає в тому, що скільки потоків дозволено відразу ж купувати ресурс?
- Mutex - є ОДИН.
- Семафор - його DEFINED_COUNT, (як і кількість семафорів)
М'ютекс використовується для послідовного доступу до ресурсу, в той час як семафор обмежує доступ до ресурсу до заданого числа. Ви можете думати про м'ютексів як семафор з числом доступу 1. Незалежно від того, що ви встановили для семафора, чи можна потоки отримати доступ до ресурсу до того, як ресурс заблокований.
Відповідь Feabhas вельми важливий - м'ютекс перевіряє потік, який намагається звільнити м'ютекс, фактично його власником. У мене було це як питання інтерв'ю, тому варто спробувати запам'ятати його.
Об'єкт синхронізації Семафор реалізує класичний світлофор. Світлофор контролює доступ до ресурсу, спільно використовуваному лічильником. Якщо лічильник більше нуля, надається доступ; Якщо він дорівнює нулю, доступ заборонений. Лічильник підраховує дозволу, що дозволяють доступ до загального ресурсу. Потім для доступу до ресурсу потік повинен отримувати дозвіл від світлофора. Загалом, для використання світлофора потік, який хоче отримати доступ до загального ресурсу, намагається отримати дозвіл. Якщо кількість світлофорів більше нуля, потік отримує дозвіл, а кількість світлофора зменшується. В іншому випадку потік блокується до тих пір, поки він не отримає дозвіл. Коли потік більше не потребує доступу до загального ресурсу, він звільняє дозвіл, тому кількість світлофора збільшується. Якщо є ще один потік, який чекає дозволу, він набуває дозвіл в той час. Семафорскій клас Java реалізує цей механізм.
Семафор має два збирача:
num вказує початковий рахунок дозволу. Потім num вказує кількість потоків, які можуть звертатися до загального ресурсу в даний момент часу. Якщо num дорівнює одиниці, він може одночасно звертатися до ресурсу по одному потоку. Встановивши come як істинний, ви можете гарантувати, що потоки, які ви очікуєте, отримали дозвіл в тому порядку, в якому вони просили.
Лічильний семафор. Концептуально семафор підтримує набір дозволів. Кожен acquire () блокує, якщо необхідно, до отримання дозволу, а потім бере його. Кожен release () додає дозвіл, потенційно звільняючи блокуючого покупця. Однак фактичні об'єкти дозволу не використовуються; Семафор просто підраховує кількість доступних і діє відповідно.
Семафори часто використовуються для обмеження кількості потоків, ніж доступ до деякого (фізичній або логічного) ресурсу
Java не має вбудованого API Mutex. Але він може бути реалізований як двійковий семафор.
Семафор, ініціалізований одним, і який використовується так, що він має не більше одного доступного дозволу, може служити блокуванням взаємного виключення. Це більш широко відомо як двійковий семафор, оскільки він має тільки два стани: один дозвіл є або нульові дозволу доступні.
При використанні таким чином двійковий семафор має властивість (на відміну від багатьох реалізацій блокувань), що «блокування» може бути випущена потоком, відмінним від власника (оскільки семафори не мають поняття власності). Це може бути корисно в деяких спеціалізованих контекстах, таких як відновлення взаімоблокіровок.
Отже ключові відмінності Між Семафор і М'ютекс:
Семафор обмежує кількість потоків для доступу до ресурсів. Mutex дозволяє тільки одному потоку звертатися до ресурсу.
Жоден з тим не володіє Семафор. Теми можуть оновлювати кількість дозволів, викликаючи методи acquire () і release (). М'ютекси повинні бути розблоковані тільки потоком, який утримує блокування.
Коли м'ютекс використовується зі змінними стану, є Автоматичне виведення брекетінг - ясно, що захищена частина програми d. Це не обов'язково відноситься до семафора, який може бути названий перейти до паралельного програмування - це потужний, але занадто простий у використанні неструктурований, невизначений спосіб.