semaphore

наверно можно но ведь долго, пробуй короче

Возможность использовать семафоры в обработчике прерываний
зависит от операционный системы. Большинство систем
не допускает работы с "обычными" семафорами, т.к. это "системные
вызовы" и они должны выполняться только в пространстве пользователя.
Естественно все системы имеют внутри свои аналоги семафоров
и "ядреные" вызовы.
Впрочем внутри ядра они обычно заменяются на что-то иное,
например, выполнение "атомарных" операций, блокирование прерываний,
вызовы типа wakeup. Наиболее близкий аналог семафоров в ОС - spinlock.
Они используются для многопроцессорных систем.
Что важно: в "нормальной" системе обработчик не может "заснуть"
на семафоре, только разбудить что-то. В противном случае ожидание
может стать вечным.
В некоторых системах (типа VxWorks и т.п.) операции пробуждения
семафора могут быть явно вызваны из обработчика прерываний.

io wrote:

> В некоторых системах (типа VxWorks и т.п.) операции пробуждения
> семафора могут быть явно вызваны из обработчика прерываний.

а также и в linux.

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

А по поводу скорости:
Если системные семафоры нужны для гарантии целостности, то при малых
изменения проще их избежать. И думать об этом за пределами irq.
При больщих изменениях, ожиданиях или обмене (irq сообщает что что-то
прибыло-убыло) они вполне нормальны.

Теоретически можно, но на практике это плохо кончится.

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

Обычно прерывания обрабатываются в две фазы:
быстрое прерывание (никаких семафоров, максимум - irq spin)
медленное прерывание (в контексте рабочей нити ядра - там можешь делать что угодно - для Linux это обычно tasklet, хотя в силу специфики задачи может иметь смысл использовать более низкоуровневый примитив как softirq).

taskklet это и есть softirq.

'медленное прерывание' (bottom half) не исполняется в контексте
процесса, это опять-таки softirq.

Это все interrupt context. И там можно делать далеко не все, что
угодно. Нельзя явно или неявно вызывать планировщик, читать
память прерванного процесса, GFP_ только ATOMIC и т.д.

'Все что угодно' - это keventd (schedule_task) в 2.4
и workqueues (schedule_work, queue_work) в 2.6.
могут быть инициированы из прерывания.

io wrote:

> Почти "также". В VxWorks общий набор семафоров для системы и задач.
> В Linux, если мне не изменяет склероз, это не так.

да, я имел в виду kernel semaphores.

idle:

>taskklet это и есть softirq.
tasklet это не softirq :)

Остальное, видимо, написано автору темы (я же вроде не спрашивал), так что комментировать не буду 8)

> tasklet это не softirq

а что же тогда?

tasklet_schedule()
raise_softirq_irqoff()
wakeup_softirqd()
-> do_softirq()

повторяю, tasklet тот же (устаревший) bottom half,
только без global serialization.

Остальное написано в ответ на утверждение, что
tasklet выполняется в контексте рабочей нити
ядра (что неверно), и что там можно делать
что угодно (опять-таки неверно).

На всякий случай, пока кто-нибудь не придрался,
добавлю.

Если (как правило) машина не перегружена прерываниями,
tasklet будет выполнен непосредствено из обработчика
прерывания: do_IRQ() вызывает do_softirq().

Просто удивительно как Murr любит перебарщивать.
Как утверждают выпускники ВМК их таки синхронизации не учат,
а жаль.
1. Как это не странно, но семафоры используются для пробуждения
из irq. Для VxWorks это достаточно типично, для linux
менее типично, но, например, в scsi (вот уж где бы я их
не стал применять) найти пример можно.
В большинстве драйверов Linux семафоры и правда используются
исключительно как мутексы для защиты данных (про целостность
я впрочем писал выше, но Murr не читаталь). Именно в такой роли
их в irq быть не должно и никаких deadlock-ов не будет.
2. С его точки зрения Murr семафоры и мутексы это одно и тоже.
Семафоры используются и просто для передачи событий (именно
это можно найти в scsi драйверах). Уж как правило говорят минимум
о событийных, счетных и блокирующих семафорах.
Про PV семафоры, альфа и бэта блокировку я уж и говорить не буду.
3. Как это не грустно так таки мутексы встречаются и в irq.
Достаточно поискать строки с SMP в ifdef в драйверах.
Это те самые spinlock-и про которые я тоже уже упоминал выше.
Только они являются полным аналогом семафоров для работы
внутри irq, т.е. используются и для того, чтобы заснуть и для
того, чтобы проснуться.
4. Контекстное переключение написано (как говориться в книжках
по технологии программирования) в стиле Statable шаблона.
Это достаточно хороший (иногда единственно надежный) шаблон
для работы в параллельных системах. Крыше там ехать некуда.
5. Имеется явная путаница между контекстным переключением и
его "инициацией". Это моменты разнесенные во времени.

Ну и еше пару слов по поводу скорости. Естественно, если
чип, драйвер для которого мы пишем, быстродействующий,
может работать с DMA, действует в пакетном режиме, то для него более
правильно импользовать различные очереди. Благо их типов во всех ОС
всегда много.
Если же устройство туповато, предполагает последовательную обработку событий, посылку команд, ожидание обработки и т.п.
(т.е. имеется многостадийность), то что мешает использовать те же
событийные семафоры? Ничто! Поэтому при больших ожиданиях
(об этом я тоже писал) такое решение возможно и нормально.

Т.е. на вопрос "можно?" ответ именно "можно".
На вопрос об оптимальности ответ "вполне возможно что нет".