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

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

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

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

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

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

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

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

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

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


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


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

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

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

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

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


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

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

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

Так говорили лет 15..20 назад, когда еще делили программистов на два лагеря: PC и PIC-контроллеры ...
К счастью, на дворе совсем другие времена, та "грань" практически размыта и поэтому очередная попытка подобного деления звучит уже как минимум наивно
Не отставайте, а то затопчут :D

1. Глобальные переменные в большинстве случаев нарушают инкапсуляцию. К ним открыт неконтролируемый доступ отовсюду.
2. В большом проекте при обилии глобальных переменных возникает путаница в именах. Глобальную переменную же видно отовсюду, надо, чтобы отовсюду было понятно, зачем она.
3. Глобальные переменные в большинстве случаев нарушают принцип инверсии зависимостей (или делают возможным его нарушение).
4. Глобальные переменные ухудшают масштабируемость проекта.
5. Глобальные переменные ухудшают читаемость кода (в каком-то конкретно взятом месте непонятно, нужна ли какая-то конкретная глобальная переменная, или нет).
6. Глобальные переменные приводят к трудноуловимым ошибкам. Примеры: нежелательное изменение её значения в другом месте/другим потоком, ошибочное использование глобальной переменной для промежуточных вычислений из-за совпадения имен, возвращение функцией неправильного значения при тех же параметрах (оказывается, она зависима от глобальной переменной, а ее кто-то поменял).
7. Глобальные переменные создают большие сложности при использовании модульного тестирования.
8. Глобальные переменные увеличивают число прямых и косвенных связей в системе, делая её поведение труднопредсказуемым, а её саму - сложной для понимания и развития.

Взято отсюда.

Даже если "вброс" - одобрямс.
"Проблем" в том, что найти оптимальную-умную ссылку из нескольких сотен, что вываливает поисковик - уже сама по себе задача сложная.
Чтобы выудить из этой свалки внятный ответ на свой вопрос нужно угрохать много времени. То, что наилучшая инф. находится на первых двух страницах - не факт.
Искатель рискует получить в голове грандиозную кашу из информации и дез-информации
По данной теме это может и не так, но если вопрос чуть сложнее - то факт есть факт.

Отсюда:
https://electronix.ru/forum/index.php?showt...t&p=1547597

Если не учиться в детстве ходить и бегать, то так и будешь всю жизнь ползать и звать на помощь мамку по всяким пустякам

Использую по прямому назначению, чтоб избегать инверсии приоритетов. Если в системе с десяток процессов и большинству нужен доступ к разделяемым ресурсам (таким как dma или в5ешняя память), то исключить возможность инверсии приоритетов (и контроля над тем, что происходит) неполучается без этого. Заводить для каждого общего ресурса отдельный поток и очередь сообщений - не вариант (т.к. таких ресурсов много, а ОЗУ всегда в дефиците, да и времени на переключение контекста жалко). А мютексы с наследованием приоритетов решают эту задачу отлично и без дополнительных расходов (ну почти).

А очереди не должны приводить к лишним переключениям контекста. Более того, могут позволить их частоту снизить, в ситуациях, когда имеется выраженная неравномерность поступления единиц обработки во времени (пачками поступают, например). Но тут да, размен емкости системы в единицах отложенной обработки на потребляемое ОЗУ и предсказуемость (число возможных состояний) )

А Вам-то что?
Здесь раздел для начинающих в форуме электронщиков/программистов как раз для выяснения простых вопросов. Чтобы ответы на них не искать по всем просторам интернета. И, как видим, они не всегда элементарны и односложны, как кажутся.
Поэтому, присоединяюсь к ViKo: нет желания разжёвывать "пустяки" - проходите, и не надо нравоучений.

Вы путаете простые вопросы, на которые трудно найти однозначные ответы, с вопросами, на которые ответы найти очень легко самостоятельно.
Первые же ссылки при поиске в гугле по запросу "мьютексы и семафоры разница" дают вполне однозначные и внятные ответы.
Вот специально для особо ленивых: ссылка раз, ссылка два, ссылка три, ну и википедия.
Не сложно, не правда ли?

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

Оно и понятно почему - каждый производитель ОС трактует эти вещи немного по-своему. А какая ОСь так и было не указано.
Тут уже озвучивали, что слишком мало исходных данных, поэтому вполне логично, что однозначного ответа тут не прозвучало и не прозвучит.
Имхо, именно так рождают холивары и срачи.

Где я с этим и спорил??
Все мои "вопросы" к элементарной лени ТС. Не более того.


А вот тут я как-нибудь сам разберусь на что и сколько мне тратить своё время!

Эт не ответ. Такие рассуждения сопровождают любой мануал по RTOS.
Меня интересует прежде всего с чего вы взяли что у вас возможна инверсия, а если и возможна то с чего вы решили что с ней надо бороться или что она реально опасна.
Не проще ли было спланировать приоритеты так чтобы не было инверсии или от нее не исходила бы опасность?
Скажем у меня десятки задач, но я не боюсь инверсии.
Вот мьютексов я боюсь, поскольку они съедают кучу процессорного времени и внутри их сервисов происходят длительные запреты прерываний.



Столько ссылок и все не в тему.
Вы че совсем не знаете RTOS?
Не знаете где FreeRTOS лежит или mbed?
Лень было туда сходить и посмотреть?
Обязательно этот шлак из первой страницы поиска гугли выгружать?

Прочитайте первый пост еще раз. На этот раз более внимательно и вдумчиво.
Потом дайте свои ссылки "в тему".


ТС ни слова не сказал ни про то, ни про другое. Вы экстрасенс? Умеете читать мысли?

Если TC молчит, то поддерживаем обсуждение в рамках тематики форума.
Вернитесь в начало форума и посмотрите его тематику.

Скажите, где учат так выкручиваться от ответов на прямые вопросы?

И стоит ли ждать от Вас ссылок "в тему", или хотя бы "в рамках тематики форума"?
Ведь мои ссылки про "разницу между семафором и мьютексом" вдруг оказали "не в тему" ((

ТС не молчит, праздники...
спасибо за обсуждение, с интересом почитал
Никакого холивара не планировалось, столкнулся с этим делом в рамках CMSIS Rtos и Keil RTOS
Вывод в порт дебажный сделал и так, и так. Разницы не увидел, поэтому и спросил
А операционки да, все разные. Тут жизнь заставила делать под линух, так там с сигналами, например, совсем другая идеология, сижу, разбираюсь...

Мануал RTX говорит очень однозначно:
Semaphores are used to manage and protect access to shared resources. Semaphores are very similar to Mutexes.

Отличия:
Whereas a Mutex permits just one thread to access a shared resource at a time, a semaphore can be used to permit a fixed number of threads to access a pool of shared resources.
Using semaphores, access to a group of identical peripherals can be managed (for example multiple DMA channels).

Мьютекс по сути - вырожденный семафор (бинарный), но имеющий дополнительное ограничения:
Mutex management functions cannot be called from interrupt service routines (ISR), unlike a binary semaphore that can be released from an ISR.

Но есть у мьютекса и особая "фича":
The advantage of a mutex is that it introduces thread ownership.
When a thread acquires a mutex and becomes its owner, subsequent mutex acquires from that thread will succeed immediately without any latency.
Thus, mutex acquires/releases can be nested.

Поэтому "Вывод в порт дебажный" будет работать одинаково как на мьютексе так и на семафоре.

По крайней мере так сделано в Keil RTX. В других ОСях это может немного отличаться.
С точки зрения реализации и производительности это также очень сильно зависит от конкретной RTOS.

А вот тут я Вам напомню о Правилах Форума. Можете тратить его на что угодно, но не на флейм здесь. Настоятельно прошу воздержаться впредь от наездов и приреканий.