[Forger 17]

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

Так говорили лет 15..20 назад, когда еще делили программистов на два лагеря: PC и PIC-контроллеры ...

К счастью, на дворе совсем другие времена, та "грань" практически размыта и поэтому очередная попытка подобного деления звучит уже как минимум наивно ;)

Не отставайте, а то затопчут :D

 

1. Глобальные переменные в большинстве случаев нарушают инкапсуляцию. К ним открыт неконтролируемый доступ отовсюду.

2. В большом проекте при обилии глобальных переменных возникает путаница в именах. Глобальную переменную же видно отовсюду, надо, чтобы отовсюду было понятно, зачем она.

3. Глобальные переменные в большинстве случаев нарушают принцип инверсии зависимостей (или делают возможным его нарушение).

4. Глобальные переменные ухудшают масштабируемость проекта.

5. Глобальные переменные ухудшают читаемость кода (в каком-то конкретно взятом месте непонятно, нужна ли какая-то конкретная глобальная переменная, или нет).

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

7. Глобальные переменные создают большие сложности при использовании модульного тестирования.

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

 

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

[k155la3 26]

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

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

Даже если "вброс" - одобрямс.

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

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

Искатель рискует получить в голове грандиозную кашу из информации и дез-информации :)

По данной теме это может и не так, но если вопрос чуть сложнее - то факт есть факт.

 

 

 

[ViKo 1]

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 17]

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

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

[Viktuar 0]

Да не использую.

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

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

[dii# 0]

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

[Herz 4]

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

А Вам-то что?

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

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

[Forger 17]

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

Вы путаете простые вопросы, на которые трудно найти однозначные ответы, с вопросами, на которые ответы найти очень легко самостоятельно.

Первые же ссылки при поиске в гугле по запросу "мьютексы и семафоры разница" дают вполне однозначные и внятные ответы.

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

Не сложно, не правда ли? ;)

[Herz 4]

Я согласен, многое можно выяснить самостоятельно. И даже говорят, при правильном подборе литературы, получить неплохое образование, не покидая туалет.

Меня тоже, например, раздражает лень нерадивых студентов, не желающих палец о палец ударить, чтобы решить домашнее задание (по определению требующее самостоятельности).

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

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

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

Так что, ради реплики типа: "имей совесть - поищи сам" не стоило утруждаться.

[Forger 17]

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

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

Тут уже озвучивали, что слишком мало исходных данных, поэтому вполне логично, что однозначного ответа тут не прозвучало и не прозвучит.

Имхо, именно так рождают холивары и срачи.

 

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

Где я с этим и спорил??

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

 

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

Так что, ради реплики типа: "имей совесть - поищи сам" не стоило утруждаться.

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

 

[AlexandrY 3]

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

Эт не ответ. Такие рассуждения сопровождают любой мануал по RTOS.

Меня интересует прежде всего с чего вы взяли что у вас возможна инверсия, а если и возможна то с чего вы решили что с ней надо бороться или что она реально опасна.

Не проще ли было спланировать приоритеты так чтобы не было инверсии или от нее не исходила бы опасность?

Скажем у меня десятки задач, но я не боюсь инверсии.

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

 

 

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

Не сложно, не правда ли? ;)

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

Вы че совсем не знаете RTOS?

Не знаете где FreeRTOS лежит или mbed?

Лень было туда сходить и посмотреть?

Обязательно этот шлак из первой страницы поиска гугли выгружать?

[Forger 17]

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

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

Потом дайте свои ссылки "в тему".

 

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

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

[AlexandrY 3]

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

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

Вернитесь в начало форума и посмотрите его тематику.

[Forger 17]

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

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

 

И стоит ли ждать от Вас ссылок "в тему", или хотя бы "в рамках тематики форума"?

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

[toweroff 0]

ТС не молчит, праздники...

спасибо за обсуждение, с интересом почитал

Никакого холивара не планировалось, столкнулся с этим делом в рамках CMSIS Rtos и Keil RTOS

Вывод в порт дебажный сделал и так, и так. Разницы не увидел, поэтому и спросил

А операционки да, все разные. Тут жизнь заставила делать под линух, так там с сигналами, например, совсем другая идеология, сижу, разбираюсь...