Нет. Мьютекс достается только одной задаче. Если одна задача получила мьютекс, то, значит, у другой его не было. То есть, и отдавать другой задаче нечего.
Я не пробовал выполнять osMutexRelease до его получения. Но, думаю, просто ничего не произойдет.

Вот это и называется - задача владеет мьютексом. Захватила, и владеет единолично, пока не отдаст. Это я к вашей фразе

Теперь видите разницу?

Почитайте выше, что пишет топикстартер, У него мьютекс всегда принадлежит одной и той же задаче. Вот ему я и пишу, что у Кейла - не так. Мьютекс создает ОС, задачи им пользуются.

Перечитал сообщение 26. В начале говорится о заблокированном мьютексе, а потом уже просто о владельце. Я неправильно понял.

Вы меня совершенно неправильно поняли. Где именно я так неясно выразился?

Конечно, мютекс принадлежит той задаче, которая его захватила. Когда задача его разблокирует, он снова ничей.
А семафор ничей даже когда задача его "захватила" (в кавычках - потому что некорректный термин для семафора). И в этом главное отличие семафоров от мютексов.

Когда задача А заблокировала мютекс, задача Б не может его разблокировать.
Когда задача А "заблокировала" семафор, задача Б (или даже прерывание) может его "разблокировать".

Не знаю как у Кейла, может, и не так. Это не новость, что эти термины постоянно путаются, к сожалению. Ну еще раз дам ссылку на статью: Mutexes and Semaphores Demystified, почитайте там хотя бы The Myth: Mutexes and semaphores are similar or even interchangeable, а также The History of Semaphores and Mutexes.

Хотите семафоров? - их есть у Кейла. Как говорится, найдите отличие от мьютекса.
То же, что в статье и dimonomid называют семафором, у Кейла выполняют "сигналы" (osSignalSet, osSignalClear, osSignalWait), они же в девичестве "события" (Event), они же "флаги". Они принадлежат задаче (по умолчанию у каждой задачи их 16 штук), и могут обрабатываться поодиночке или группой.

Еще предлагаю посмотреть документ от Кейла:
http://www.keil.com/product/brochures/rl-arm_gs.pdf
Синтаксис устарел, но принципы остались теми же. В-частности, там показано, как используются семафоры: Сигнализация, Мультиплекс, Рандеву, Турникет.

Ай пошли войны. Создали бы тему или блог какой и обсуждали бы краеугольные камни архитектуры ПО.
Мне бы больше хотелось увидеть сравнение времени переключения контекста от количества задач между TNeo и той же FreeRTOS (порт для pic32 ) . Да и по памяти выделяемой на те же объекты синхронизации.
У меня пока что руки дошли запустить-помигать. Исходный код у проекта выглядит очень приятно. Попробую прикрутить гармониевский стек, заодно буду смотреть что у TNeo с менеджером динамической памяти.

Нашел принципиальное отличие мьютекса от семафора.
Мьютекс при инициализации получает значение (условно) 1. При использовании, когда мьютекс забирается, он становится равным 0. Когда возвращается, снова 1.
Семафор при инициализации может получить любое значение, N, в том числе и 0 (закрыт). Вот этот 0 и позволяет использовать семафор в различных иных применениях, кроме доступа к ограниченному количеству ресурсов.
Так что, разница есть. Но и говорить, что мьютекс - частный случай семафора - тоже верно.

Принципиальная разница в том, что освободить мьютекс может только тот, кто им в настоящий момент владеет. У семафора нет такого ограничения.

Точно.

Прошу прошения.
А почему такой древний компилятор XC32 v1.21?

Нет особых причин, соберите новым компилятором, проблем быть не должно.

Насчет FreeRTOS:




Ради интереса, таки провел сравнение, вопреки лицензии FreeRTOS. Пример простейший: две задачи: А (высокоприоритетная) и B (низкоприоритетная). А ждет семафора, B через определенный интервал сигналит семафором. Т.к. А высокоприоритетная, то как только B сигналит семафором, управление передается задаче А.

Измерял время от момента вызова сервиса сигнализирования из задачи B до получения управления задачей А.

В TNeo: 624 тиков (594 с отключенной проверкой переполнения стека),
в FreeRTOS: 1215 тиков (1075 с отключенной проверкой переполнения стека).
UPD: в FreeRTOS: 863 тиков (699 с отключенной проверкой переполнения стека). Я по запаре накосячил с измерениями первый раз, см. след. сообщение.

Измерения производились на PIC32MX с помощью stopwatch в MPLABX.

TNeo:


FreeRTOS:


Сообщение отредактировал dimonomid - Apr 8 2015, 09:59

Так, отставить, я ерунду написал в прошлом сообщении: для TNeo-то я взял существующий настроенный проект, а для FreeRTOS создал новый, и забыл в нем оптимизацию включить. Пардон.

Так что отличия поскромнее:

В TNeo: 624 тиков (594 с отключенной проверкой переполнения стека),
в FreeRTOS: 863 тиков (699 с отключенной проверкой переполнения стека).

Насколько я помню, автор FreeRTOS всегда упирал на большую предсказуемость. Т.е. две задачи - не показатель, а вот что будет с 20 задачами - вопрос интересный.
Простой пример: TNeo реализует таймеры как callback-и из обработчика таймерного прерывания (я не ошибся?). Какой смысл говорить о времени переключения контекста в таком раскладе? Переключение реально не произойдет до тех пор, пока не будут отработаны все таймеры. Т.е. задержка не детерминирована, совсем.

Сообщение отредактировал LightElf - Apr 8 2015, 14:20

Как в FreeRTOS - не знаю, а в TNeo, как и в TNKernel, количество задач не влияет на скорость переключения контекста: для каждого приоритета есть связанный список задач, готовых к запуску. И есть битовая маска, каждый бит которой отражает приоритет, в котором есть готовые к запуску задачи. Таким образом, когда ядро выясняет, какую задачу нужно запустить, оно делает следующее:

- Находит номер младшего установленного бита в маске. Некоторые архитектуры имеют специальную инструкцию для этой операции (Find first set). Если такой инструкции нет, то приходится вручную проверять каждый бит, но тогда время выполнения зависит не от количества задач, а от количества приоритетов.
- Передает управление первой задаче из связанного списка для соответствующего приоритета. Время константное.


От количества задач эта задержка тоже не зависит.

Сообщение отредактировал dimonomid - Apr 8 2015, 14:16