[linux] Переключение тредов при irqsave + TASK_INTERRUPTIBLE

Dasar

в одном из исходников сейчас встретил следующий код (set_current_state идет после lock, хотя обычно рекомендуют его ставить после unlock, если по результату лока выяснилось что делать нечего):



  bla-bla



  spin_lock_irqsave(..);

  set_current_state(TASK_INTERRUPTIBLE);

 

   bla-bla

  

  spin_unlock_irqrestore(..);

переключение на другие треды внутри куска кода с наложенным spin_lock при таком коде происходить будет? или нет?

salamander

spin_lock_irqsave ведь запрещает прерывания, так? Тогда и переключиться это ядро никуда не сможет, пока их обратно не разрешат. При этом на других ядрах может работать что угодно.
PS: Я не знаю, насколько вообще понятия тредов/процессов применимо к коду ядра линукса, если тут про ядро речь, конечно. (фигню написал, есть ядерные треды)
PPS: http://www.linuxjournal.com/article/5833

Dasar

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

переключение тредов происходит только по прерываниям? других способов нет?

vall

контекст джважды атомарный — во первых спинолок во вторых прерывания запрещены
переключение контекста бывает voluntary (явный вызов schedule/cond_resched или любой спящей операции) и
preemptive (из контекста залётного прерывания или явный wakeup другой задачи).
для preemptive нужен preempt-counter чтоб атомарность контекста выяснять, _но_ local_irq_disable/
local_irq_save preempt-counter не поднимают. т.к. по контексту и так понятно.
Работает это обычно так: кто-то выставляет TIF_NEEDRESCHED а при выходе из прерывания
он проверяется и если можно спать то уходит в schedule.
с current->state есть тонкие моменты с баръерами и рэйсом вокруг засывания/пробуждения:
нужно выставить спящий стэйт и записать его в пямять до проверки условия засыпания чтоб не
порэйсится с тем кто будет параллельно будить. set_current_state есть с баръером и без —
в зависимости от контекста можно обойтись без лишнего барьера если он и так есть в спинлоке или атомике.
в spin_unlock насколько я помню баръера нет, хотя возможно с тикетлоками уже есть. хз.

Оставить комментарий