Семафоры и Мютексы Опции

[toweroff]

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

[Serge V Iz]

мютекс - вырожденная форма семафора с количеством вхождений ==1

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

[Arlleex]

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

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

[Forger]

Товарищи, объясните разницу ...

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

[ViKo]

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

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

[haker_fox]

Товарищи, объясните разницу

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

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

[jcxz]

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

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

[Forger]

По какой конкретно ссылке?

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

[haker_fox]

Не знаю с чего Вы это взяли

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

вполне себе много лет уже использую семафоры

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

Для разделяемого доступа к ресурсам я могу применять хоть семафоры, хоть мьютексы, хоть даже мэйлбоксы или критические секции (или вообще сделать разделяемый доступ на атомарных операциях LDREX/STREX и Sleep(); или очередях и Sleep()) - всё зависит от понимания работы инструмента и уровня компетентности разработчика.

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

[AlexandrY]

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

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

[Viktuar]

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

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

[Forger]

Но при этом можно сделать destroy мьютекса из другой задачи, не в той в которой он был залочен.

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

[AlexandrY]

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

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

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

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

[Forger]

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

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

[AlexandrY]

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

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

[Forger]

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

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

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

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

[k155la3]

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

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

[ViKo]

Mutex stands for “Mutual Exclusion”. In reality, a mutex is a specialized version
of semaphore. Like a semaphore, a mutex is a container for tokens. The
difference is that a mutex can only contain one token which cannot be created or
destroyed. The principle use of a mutex is to control access to a chip resource
such as a peripheral. For this reason a mutex token is binary and bounded. Apart
from this it really works in the same way as a semaphore.

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

[Forger]

"Проблем" в том, что найти оптимальную-умную ссылку из нескольких сотен, что вываливает поисковик - уже сама по себе задача сложная.

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

[Viktuar]

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

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

[Serge V Iz]

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

[Herz]

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

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

[Forger]

Здесь раздел для начинающих в форуме электронщиков/программистов как раз для выяснения простых вопросов.

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

[Herz]

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

[Forger]

Как Вы могли заметить, у отвечающих тоже не нашлось однозначного ответа.

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

Поэтому пользу обсуждения не стоит недооценивать.

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

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

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

[AlexandrY]

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

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

Вот специально для особо ленивых: ссылка раз, ссылка два, ссылка три, ну и википедия.
Не сложно, не правда ли?

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

[Forger]

Столько ссылок и все не в тему.

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

Вы че совсем не знаете RTOS? Не знаете где FreeRTOS лежит или mbed?

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

[AlexandrY]

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

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

[Forger]

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

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

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

[toweroff]

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

[Forger]

в рамках 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.

[Herz]

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

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