Товарищи, объясните разницу
Мютекс - запрещает доступ от разных процессов
Семафор - имеет счетчик вхождений
получается, мютекс - вырожденная форма семафора с количеством вхождений ==1?

в плане абстрактной логики примитивов синхронизации.
В плане конкретной реализации он может быть более быстродействующим.

Не совсем так.
Мьютекс - это объект синхронизации, имеющий состояния "захвачен" и "отпущен", причем отпустить мьютекс может только тот процесс, который его захватил, в отличие от семафоров. Не забывайте, что есть еще счетные семафоры, а также рекурсивные мьютексы. У них у обоих счетчик захватов/сигнализации увеличивается/уменьшается, только вот опять же, освободить мьютекс может только занявший его процесс. При обработке мьютекса ОС проверяет принадлежность объекта синхронизации к текущему процессу. В случае семафора - нет.

Сообщение отредактировал Arlleex - Jun 9 2018, 17:14

Вот по этой ссылке про это все очень доходчиво расписано. Очень полезный ресурс, рекомендую!

По какой конкретно ссылке? Если нечего сказать, не говори ничего.
Я согласен со стартовым сообщением. Все остальное - шелуха и заумь.

Своими словами: мьютекс предназначен для "атомарного доступа". И это доступ к переменным, аппаратному обспечению, коду и т.п. Если один из процессов желает получить доступ к общему ресурсу (который и другие процессы могут использовать), то сначала он должен захватить мьютекс. Если мьютекс свободен, то процесс сразу получает доступ к ресурсу. В противном случае он вынуждет ждать - в течение указанного таймаута. Может дождаться, а может и не дождаться.

Семафоры предназначены для "сигнализации" одним процессом другому. Например, наша задача "А" должна дождаться, пока другая задача "В" выполнит какой-то фрагмент когда, затем послать сигнал в ждущую задачу "А". Задача "А", в свою очередь может продолжить выполняться.

Не знаю с чего Вы это взяли, но я на uCOS-II вполне себе много лет уже использую семафоры для разграничения доступа задач ОС к разделяемым ресурсам.
И вообще, имхо, значения этих терминов в разных ОС трактуются не одинаково.
Так что вопрос терминологии бессмысленен без привязки к конкретной ОС.
К тому же исходный вопрос ТС ещё и поставлен некорректно: вопрос "в чём отличия функциональности" и "для чего можно применять" - совершенно разные вопросы. Для разделяемого доступа к ресурсам я могу применять хоть семафоры, хоть мьютексы, хоть даже мэйлбоксы или критические секции (или вообще сделать разделяемый доступ на атомарных операциях LDREX/STREX и Sleep(); или очередях и Sleep()) - всё зависит от понимания работы инструмента и уровня компетентности разработчика.

По любой ссылке, которая ведет в поисковик, поскольку вопрос этот из ясельной группы.
Вангую, что это был банальный "вброс" с известной целью. Ведь вон как на него отреагировали

Я вам сейчас всё расскажу. Сегодня по утру я скосил знатную долю ганджубаса на своём поле. Увидев поставленный автором вопрос, я подумал, а почему бы и мне не ответить. Раскурив косячок, и подсоединившись к мировому сознанию, я написал то, что мне пришло в моём видении. И заметьте, это не учитывая более, чем два года работы с FreeRTOS, и более, чем 10-летним знакомством и работой с scmRTOS.


А я разве говорил что-то обратное? Я лишь ответил автору вопроса на поставленный вопрос, и специально дал оговорку "своими словами". Впрочем оговорка была лишней, тут и так никто на истину в первой инстанции претендовать не может.


Я тоже их применяю. Неразумно защитать одну 4-байтовую переменную мьютексом и дёргать шедулер, когда там проще использовать критическую секцию. Так и сделано в одном из моих проектов. А вот аппаратный SPI я отдал одной из задач (роутеру), и и дал ему очередь, из которой он бесконечно долго ждёт сообщений. Сообщение может послать любой процесс, или даже прерывание. Тут я пришёл к выводу, что мьютекс или критическая секция совершенно не уместны.
Как видите, по одному лишь ответу трудно судить о компетентности. Всё зависит от понимания работы другого человека и уровни компетентности разработчика.

Но при этом можно сделать destroy мьютекса из другой задачи, не в той в которой он был залочен.
И он разлочится для всех остальных задач. Разница в поведении с семафорами здесь эфемерная.
Так что мьютексам найти достойное применение очень сложно. Я их никогда не использую.
Гораздо удобнее для этого Lightweight Semaphores. Они и быстрее мьютексов создаются, и лочат задачи в два раза быстрее.

А как же "priority inheritance" в мьютексах? Его вы тоже не используете?

Достаю свою "шарманку": если не делать мьютекс глобальным (доступным со "всех щелей"), то такая проблема ему не грозит. Впрочем, как и любому другому "объекту"

Это не проблема, а такая фича, которой надо пользоваться раз она есть.
Поэтому все что можно надо делать глобальным, иначе лишаетесь кучи полезных фичей.


Да не использую.
А вы используете? Расскажите как.

Вы аккуратнее шутите! Все-таки, это - раздел для новичков, и некоторые из них могут воспринять "это" всерьез!

Дело в том что программирование малых embedded систем - это несколько иная наука чем программирование скажем PC или даже одноплатных компьютеров.
Но это открывается только через достаточно лет практики.
Поэтому я не удивляюсь незнанию вами таких очевидных истин.