Interrupt lock 과 task switching
안녕하세요.
저는 현재 VxWorks 를 사용하여 Embedded system 을 개발하는 사람입니다.
어떤 필요성에 의해서 VxWorks 의 interrupt lock 기능을 제공하는 intLock() 함수를 사용하게 되었는데요..
그 함수의 description 을 보니 다음과 같았습니다.
The routine intLock( ) can be called from either interrupt or task level. When called from a task context, the interrupt lock level is part of the task context. Locking out interrupts does not prevent rescheduling. Thus, if a task locks out interrupts and invokes kernel services that cause the task to block (e.g., taskSuspend( ) or taskDelay( )) or that cause a higher priority task to be ready (e.g., semGive( ) or taskResume( )), then rescheduling occurs and interrupts are unlocked while other tasks run. Rescheduling may be explicitly disabled with taskLock( ). Traps must be enabled when calling this routine.
간단히 말하면, interrupt lock 상태에서라도 task block 을 야기하는 kernel service 를 호출하면 task re-scheduling 이 발생할 수 있으니, 그런 사태를 막고 싶으면 task lock 을 동시에 써라...정도 입니다.
일반적으로는 interrupt lock 이 되면 task scheduling 에 사용되는 tick ISR 도 disable 되어서 task re-scheduling 도 되지 않는다고 알고 있는데요...제가 위에서 언급한 것과 같은 VxWorks 의 interrupt lock 구간에서의 동작이 기타 다른 RTOS 에도 해당되는 것인가요? 아니면 VxWorks 만의 독특한 방식인가요?
일반적인
일반적인 OS들에서
task scheduling이 일어나는 것은
tick이 발생했을 때만은 아니고요.
보통 task가 능동적으로 잠들거나하는 경우에
scheduling하는 함수를 호출해서
re-schedule이 일어나게 하고 있습니다.
( Task는 잠들었고 switch는 안일어나면 난감하겠죠 ? )
유저가 이런 함수를 명시적으로 호출하지 않아도
이와 관련된 API들이 내부적으로 호출할테니 ;
해당 가이드라인을 따르는 것이 좋을 것 같네요.
인터럽트가 전혀 없더라도
task 들은 계속 돌아갑니다. 단 ready 상태나 suspend 상태냐만 다르죠.
이때는 꼭 DOS 를 생각하시면 됩니다. 인터럽트가 없더라도 task 가 실행중 taks_delay() 또는 세마포를 던지거나(simGive) 받을려고 하면(semTake) 그 task 보다 우선순위가 높은 higher priority task 가 실행(ready) 됩니다.
이런 API 는 바로 kernel main task에서 제공되기 때문에 scheduling lock을 하거나 하지 않는한 실행됩니다.
task_Lock 등은 짧은 시간의 critical section 을 위해서 쓰는 것이기 때문에 주의하지 않으면 먹통이 될 수 있습니다. ~~
저게요. 무슨 말이냐면요.
일반적으로 선점형이냐 아니냐에 대해서
구조적인 차이를 든다면,
interrupt 복귀시에, rescheduling을 할 수 있느냐 없으냐가 중요 관점인 듯 합니다.
만약, task1의 context에서 interrupt가 걸렸을 경우,
ISR에서 어떤 뭔가를 하고 return하였을 때,
그게 원인이든 뭐든, task가 reschedule될 가능성이 있다는 거죠.
task lock을 사용하면 그게 안되게 되는 거고요.
무슨 말이냐면,
만약, ISR에서 현재 task보다 우선순위가 높은 어떤 task를 깨웠다면,
ISR에 끝난 후, 현재 task로 돌아가는게 아니라,
그 (높은) task로 가겠죠.
그 얘기 입니다.
댓글 달기