Цитата(bmf @ Jun 10 2005, 14:42)
Цитата
Надо бы уточнить, что Вы понимаете под термином "семафар". Мутекс - семфор. И флаг события тоже семафор. Нет счетных семафоров? Да, нету. А они нужны? Приведите реальный пример на мелкой однокристаллке, где они нужны.
Вообще то чаще нужен простой бинарный. А Мутекс и Флаг события - работают здесь по другому, обратите внимание в обычном семафоре после "сигнал" только событие с большим приоритетом переведется в состояние работы, а у флага - все события которые имеют этот флаг, сначала естественно с вышим преоритетом, затем и все остальные. Совсем другая функциональность. Я не знаю никакой другой RTOS, гдебы не было этих обычных семафоров как базовый элемент взаимодействия.
Флаг - да. А если события ожидают несколько процессов, то как их все проинформировать? Заводить для каждого объект и сигналить всю пачку? Некузяво. Но если вас такое устраивает, то и заводите просто для каждого процесса свой TEventFlag, получите ровно то, что хотите. Флаг событий не заставляет использовать его одного.
У меня, кстати, за все время работы ни разу не возникло необходимости (ситуации) в той функциональности, за которую Вы ратуете - чтобы событие обрабатывал только один процесс. Ведь тут пролучается непредсказуемость: если события ждут несколько процессов, какой из них получит управление?
С другой стороны, когда несколько процессов ждут какого-то события, это, как правило, означает, что событие это широковещательное. Такая ситуация у меня была: пришла команда снаружи, все ожидающие ее проснулись. Коротко, предсказуемо и эффективно.
Вам хочется иметь этот бинарный семафор, видимо, для того, чтобы самому с его помощью наделать себе сервисов. Ведь остальные сервисы, которые имеются, они имеют именно такую функциональность - управление получает наиболее приоритетный процесс.
Каких сервисов Вам не хватает?
Цитата(bmf @ Jun 10 2005, 14:42)
По поводу безапелляционности высказываний автора, меня больше задело не содержание(хотя здесь можно поспорить),
У Вас есть дельные возражения по существу сказанного в моем предыдущем посте (об указателе стека, регистрах...)? Изложите, интересно узнать.
Цитата(bmf @ Jun 10 2005, 14:42)
а форма и категоричность высказываний: "убогий", "два норвега" "о чем думали" - для официальной документации в русском языке есть более мягкие выражения,
Ну вообще-то, это не официальный документ, а частное описалово. Стиль там вполне свободный и даже анекдоты кое-где в качестве эпиграфов присутствуют. Т.ч. все вполне в "духе".

Цитата(bmf @ Jun 10 2005, 14:42)
а то создается впечатление, что все кто юзает ATMEL тоже убогие и недалекие.
А вот это Вы зря - ничего подобного там нет и не просматривается. Есть только то, что сказано. И сказано по делу: в AVR указатель стека кривой! Это факт! Указатель стека - это один из ключевых компонентов процессора, "заточенного" под использование ЯВУ Си - об этом (особенно первое время) Атмел свистел на всех углах, заявляя, что, дескать, соорудили офигительно эффективный для С процессор, не в последней степени благодаря тесному сотрудничеству со специалистами по компиляторам фирмы IAR Systems. Как же так?!! Они его (процессор) специально делали эффективным для С, а указатель стека - ключевой компонент для эффктивной косвенной адресации, которую интенсивно используют С-компиляторы, - сделали убогим (именно убогим, если выражаться цензурно

). Что-то тут не складывается.
Цитата(bmf @ Jun 10 2005, 14:42)
По архитектуре: - я в основною юзаю DSP - там тоже применяют два стека (реально даже больше - еще для аппаратных циклов)- только это преимущество - быстрее реакция на прерывание
Извините, у DSP стек возвратов частенько аппаратный. Либо имеет отдельную память со своими шинами для этого. Чтобы параллельности достичь. А на AVR два стека тут совершенно ничего не дают - шина-то одна, все равно адрес возврата в память последовательно складыватся/извлекается - из-за чего и время реакции на прерывание 4 такта. Никакой параллельности нет. Недодуманный он, недоделанный.
Цитата(bmf @ Jun 10 2005, 14:42)
А что медленно работает с памятью - так это за один так пре тех частотах не зделаешь, у микрочипа любая команда 4 такта. И большое колличество регистров наверно как раз и должно компенсировать.
Так что все дело с какой стороны смотреть.
А с какой не смотри - вон у ТМСов с черными финами тактовые не в пример выше, а в память за такт лазят. Да еще и два раза (параллельно). Какая проблема за такт обратится к памяти? Частоты, можно сказать, детские. И ограничиваются они не логикой, а флешью. Вон FPSLIC из ОЗУ весь работает, так там он с самого начала, afair, за 30 МГц имел частоты. Не проблема. Думается, что и этот момент просто недодуманный, недоделанный. Как и перебор с регистрами и их функциональность.
«Отыщи всему начало, и ты многое поймёшь» К. Прутков