리눅스의 선점형과 비선점형을 아주 간단하게 한마디로 말하자면

몇가지 오류에 대해서 지적하고 싶군요...

어떤 프로세스도 cpu를 독점적으로 사용할수 없습니다.

우선순위에 의해 CPU 자원을 할당하며

인터럽트 디스에이블 걸오놓지 않는한 인터럽트는 어떤경우에도 유저프로세스 보다는 우선입니다.

다만 유저가 시스템콜을 호출해서 커널모드로 동작할때는

비선점형의 경우는 시스템 콜 처리후에 인터럽트를 처리하고

선점형의 경우에는 시스템 콜 처리도중에 인터럽트를 처리한다는

차이가 생깁니다.

회사에서 이런글 쓰고 있으려니까 좀 그렇긴 한데요..

제가 커널 관련분야에서 종사하고 있고

학위도 스케줄링에 관계된 것이어서 그냥 지나가기가 그렇네요.

뭐 앞에서 많은 이야기를 했기에

같은 이야기를 반복하기는 그렇고

비선점형 커널과 선점형 커널에 대한 배경이야기를 좀 하겠습니다.

인터럽트는 말그대로 "만사 제처두고 이것부터 처리해달라" 입니다.

커널 내부적으로는 인터럽트간에도 우선순위가 있습니다만

그건 무시하고 인터럽트를 처리하는 시점은

CPU가 유저스페이스에 있을때는 항상이구요.. 바로 즉시 입니다.

커널 모드에 있을때는 프레그에 세팅해놓고 커널모드에서

벗어나기 직전에 인터럽트 확인해서 처리합니다.

이런 방식이 일반적인 비선점형 커널입니다.

일반적으로 시스템콜의 구현은 간결해야 합니다. 비선점형 커널에서는 특히 그렇습니다.

시스템콜 루틴이 길어지면 시스템전체의 응답성을 매우 떨어뜨리는데요.

시스템콜 수행중에 인터럽트가 밀려있기 때문에 그렇습니다.

이 문제를 해결하기 위해서는

시스템콜을 간결하게 만들거나 시스템콜 수행도중에 중간중간

에 프리엠션 포인트를 넣어서 처리해야할 인터럽트가 있는지

확인하고 있다면 인터럽트 서비스루틴으로 점프를 합니다.

이것을 선점형 커널이라고 부릅니다.

자꾸 다른이야기를 하시는 분들이 많은데

지금 리눅스 시스템의 90% 이상은 비선점형 커널로 동작합니다.

본인의 필요에 의해서 선점형커널로 컴파일 하지 않는한

대부분 비선점형 커널로 동작합니다.

무한루프 도는 코드 넣어서 컴파일해서 돌리시고

다른 유저로 접속하거나 다른 데몬들 동작유무를 확인 하십시요.

그렇게 밖에는 더 설명을 못하겠네요..

처음에 질문하신 분은 리눅스의 선점형과 비선점형이 어떤 것을 의미하냐고 물으셨고 그것은 jika님의 말씀이 맞습니다.

선점형/비선점형 커널의 의미가 혼용되는 것 같으니 선점형/비선점형 멀티태스킹이라는 용어로 분리해보자면 선점형/비선점형 멀티태스킹의 구분은 스케쥴링 정책쪽에 해당하는 문제입니다. 윗분께서 말씀하신 선점형/비선점형 OS라는 것은 이것을 의미할 것입니다. 운영체제 책 'Operating Systems : Internals and Design Principles (Fifth Edition), William Stallings 저'를 참고해보면 이것을 스케쥴링 정책의 decision mode라고 부르고있고 정확히 Nonpreemptive(비선점)과 Preemptive(선점)라는 용어를 사용하고 있습니다. 대표적인 비선점형 스케쥴링 방식으로는 FCFS(First-Come-First-Served)가 있고, 선점형 스케쥴링 방식으로는 Round-Robin이 있습니다.

리눅스 커널은 선점형 멀티태스킹을 하고, 2.4 이하는 비선점형 커널, 2.6은 선점형 커널과 비선점형 커널을 선택할 수 있습니다.

MS윈도우즈3.1은 비선점형 멀티태스킹을 합니다. 한 어플리케이션이 시스템콜 호출, 입출력 사용 등의 방법으로 CPU를 운영체제에 넘겨주지 않으면 혼자서 프로세서를 독점합니다. 인터럽트와 시스템콜의 문제는 MS-DOS의 커널에 의존할 것 같습니다.

프로세스의 자발적 양보없이 언제든지 커널에게 선점당할수 있다는것을 의미합니다.

라고 말씀하셨는데요..

그런식의 해석은 지나치게 사전적으로 해석하신것이구요..

제가 쓴글의 내용을 조금 살펴보시면 되겠습니다만..

비선점형커널이 비자발적인 상황에서 CPU를 빼았기지 않는것은 아닙니다...

cpu 한개의 시스템에 비선점형 커널 커널이 동작한다고 가정합시다.

무한루프로 동작하는 프로세스를 만들면 이 프로세스에는

자발적으로 CPU를 반납하지 않지만 비선점커널은 다른프로세스로

일정한 규칙(스케줄링정책) 에 의거 CPU자원을 넘깁니다.

그럼 여기까지의 과정에서 과연 선점형 커널과 비선점형 커널에

무슨 차이가 있습니까?

오랜동안 몇가지의 커널 소스들을 직접 분석하고 공부했지만

여기까지 과정에서는 선점형 비선점형 커널간 구분은 의미가 없습니다.

인터럽트 처리 이외에 커널함수로의 재진입을 하는 케이스가 있나 싶습니다.

제 기억엔 없는듯한데...

바로 윗 글에 한해서는 결국 같은이야기를 서로 다르게 했다는 생각도 드는군요..

예전에 들었던 기억이 나는데, 이런거죠.

상황 : 한병의(CPU or Process 라고 가정) 술을 나누어 주는데

- 선점형 : 바텐더가 제어권을 가지고 술을 원하는 사람에게 나누어준다. 만약 그사람이 다운되어도 술은 계속 나누어 줄수 있다.

- 비선점형 : 바텐더가 아니고 1병의 술을 각자가 돌아가면서 따라준다. 이럴경우 술을 가진 1명이 다운되면 다른사람도 덩달아 술을 못마시게 된다는...

이런 이야기 입니다.

Linux는 앞의 것에 해당되지 않을까 합니다.
수고하세요.

제가 현재 보고 있는 문서가 이 주제와 관련이 있을지는 모르겠습니다.

문서는 인쇄를 했는데, 읽는 힘이 약해서 먼지만이 쌓여가고 있습니다.

여기에 보면 3가지로 process를 구분하더군요.

아직 스케줄링하는 부분을 읽지 못했으므로, 여기까지 쓰도록하겠습니다.

Different books on operating systems define a "process" in different ways, starting from "instance of a program in execution" and ending with "that which is produced by clone(2) or fork(2) system calls". Under Linux, there are three kinds of processes:

* the idle thread(s),
* kernel threads,
* user tasks.

-- 덧붙이는 글 --
참고가 되었으면 좋겠습니다.

http://www.faqs.org/docs/kernel_2_4/lki-2.html

kernel mode에서 인터럽스가 처리가 안 된다면,

cli()와 save_cli()는 왜 불리는거라고 생각하십니까 ? ^^

forhopes 님 "kernel mode에서는 interrupt가 처리되지 않는다는 "

제글 어디에 저런 말이 있나요..

제글 표현 하나하나 신경써서 읽어주시기 부탁드립니다.

시스템콜 "수행도중" 에 인터럽트를 처리할수 없다 라고

분명하게 그것도 여러번 적시 했습니다.

커널은 분명 인터럽트처리를 최 우선으로 처리해야 합니다.

당연한 이야기 이죠..

그걸 몰라서 장대한 댓글들을 달고 있는게 아니라는걸 알아주셨음 합니다.

그리고 위에 윗글에서 손님 아이디 사용하시는분은

비자발적 컨텍스트 스위치 이야기를 하셨는데요..

전체적으로 틀린 이야기 입니다.

시분할 시스템에서 커널모드에서 비자발적 컨택스트 스위치가 일어나지 않는 경우는 없습니다.

유저프로세스의 스케줄링과 선점형 커널 비선점형 커널 구분에는 영향이 없다는

설명 누차 했는데..

선점형 커널의 프리엠션 포인트 관련된 코드들을 좀 살펴 보시면 명확해지리라 생각합니다.

아울러 비선점형 커널에서 커널모드시 비자발적 컨텍스트가 일어나지 않는

커널을 지적해주시면 좋겠습니다.

스케줄링 정책과 선점 비선점형 커널의 구분은 연관이 없습니다.

비슷한 이야기를 자주 반복하려다 보니까 본의 아니게 어조가 좀 강해지고 격해지는것 같습니다.

차분한 마음으로 다시한번...

forhopes 님..

비선점형 커널에서..유저모드에서 인터럽트를 처리하는것이 아니고요.

시스템콜을 처리하고 리턴프럼 시스템콜 할때 인터럽트가 들어와 있는지 확인해서 수행합니다.

(영어를 쓰는게 아니라 함수이름을 그냥 쓰는거니까 재수없게 생각은 말아주세요.. )

다시 말해서 시스템콜 수행후 유저모드로 돌아가기 직전에 수행한다고 하면 맞겠습니다.

저는 preemptive/non-preemptive kernel 이야기를,

jika님은 preemptive/non-preemptive OS 이야기를 하시는 듯합니다.

Linux 2.4까지는 non-preemptive kernel 이며 preemptive OS입니다.

Linux 2.6은 preemptive kernel 이며 preemptive OS입니다.

여기까지 맞나요 ?

linux 커널이 시스템콜에서 리턴 될 때만 인터럽트가 처리된다면,

cli()를 커널코드 작성시 사용할 이유가 없어집니다.

하지만, 실제로 linux kernel 소스를 보면 cli()를 무진장 씁니다.

cli()는 인터럽트 처리를 막도록 하는 함수입니다.

즉, 리눅스 커널에서는 강제가 인터럽트를 막지 않는한 시스템콜 처리중에도 처리된다는 뜻입니다.

저의 의견은 이러합니다.

선점형 커널이라는 단어와 선점형 OS 라는 단어를 구분해서 전체를 정리해주시려는 분들이 많군요..

두 용어를 구분하는건 제가 생각하기에는 적절치 않은듯 합니다.

굳이 구분하자면 선점형 커널 혹은 OS VS 선점형 멀티테스킹 혹은 선점형 스케줄링으로 구분해야 합니다.

두가지는 분명 다른 개념입니다.

후자의 개념 즉 선점형 멀티테스킹( 선점형 스케줄링은 ) 이라는 용어는

10~20년 전에 만들어진 개념이죠

당시에 시분할 시스템이 처음 도입되기 시작할때쯤 아마 이런 구분이 필요했을듯도 합니다.

하지만 현재 사용되는 임베디드 운영체제같은 자그만 OS 도 전부 다 시분할 시스템입니다.

비선점형 멀티테스킹을 한다는것 자체가 스케줄링을 거의 포기한것이나 다름없는데다가

응답성을 전혀 기대할수 없기 때문입니다. 수행되는 테스크의 수도 지나치게 많은 현실이구요..

그래서 현용하는 거의 전부의 운영체제는 시분할 시스템입니다.

다시 말해서 선점형 멀티테스킹 혹은 선점형 스케줄링을 말합니다.

고로 비선점형 멀티테스킹이니 비선점형 스케줄링이니 하는말은

50~60대의 나이드신 교수님이나 옜날책 가지고 컴퓨터 역사를 공부하는 학생들 한테나

의미가 있는 말이지 쓸모가 거의 없어진 개념입니다.

이 쓰레드 처음 만드신 질문자도 역시 이 개념을 기반으로 질문하신게 아닙니다.

여기에 올라오는 글들은 많은 분들이 오랜 시간동안 참고로 합니다.

저역시 이곳에서 좋은 정보를 많이 얻어가구요...

답글중에 전혀 사실과 다른내용이 있어서 정정하려 수차례 글들을 남기는데..

이과정에 좀 제가 잘난척한 꼴이 됬습니다.

죄송합니다.

여기 쓸만한 내용은 아니지만 커널관련 개발자가 이땅에서 격는 어려움이

어떤건지 아마 모르시는 분들이 많을겁니다.

차분해지려고 했다가 다시 흥분했다가 오늘 정신병자된 기분이네요..

"시스템콜 수행중에는 인터럽트를 처리할수 없다"
"커널모드에서는 인터럽트를 처리할수 없다"

이 두 말에 차이를 이해 못하시면 대화가 곤란합니다.
커널 함수들 중에서 시스템콜이 차지하는 비중은 아주 작습니다.

인터럽트 헨들러와 시스템 콜을 혼용 하시는데요..

인터럽트 헨들러도 넓은 의미에서는 일종의

시스템콜이라고 할수도 있겠지만 상위에서 하위로 불러드린다는 개념에서는...

제가 두단어를 동시에 사용해왔기 때문에 두가지는 다른 개념으로

이해해 주셔야 합니다.

sysinfo() 에서 cli() 호출 한다고 하시는데 제가 그버전은 없어서

확인을 못해보지만 제가 확인한 커널에서는 2.6.11.10 에서는

cli() 호출하는 구문도 없고 그에 대응하는 다른 구문도 없습니다.

물론 님이 확인하신게 잘못됬다 이야기는 아니구요.

개인적으로 리눅스소스에서 불필요한 락이나 함수 호출을 수도 없이 봤기 때문에

저는 그정도로 이해하고 있습니다만 이 부분 가지고 님을 이해해시켜 드리지는 못할듯 합니다.

마지막으로

"커널 모드에 있었다면, 그 프로세스가 우선순위가
(당연히) 가장 높기 때문에 다시 스케줄됩니다. "

이부분도 틀린 말입니다. 아니 그렇게 구현하면 그렇게 될수 있겠지만

우선 리눅스가 그렇치 않고 다른 운영체제라도 그렇게 만들어서 좋을 이유가 없습니다.

정확하게 설명하면 커널 모드에 들어와 있는 동안에

더 중요하고 급한놈이 들어왔다면 니드 리스케드라는 프레그가

세팅 되어있을겁니다.

그런 경우를 대비해서 커널모드에서 벗어날때는 해당프레그를 확인해서

더 중요하고 급한놈이 생겼다면 해당 테스크로 컨텍스트 스위치 하고

그렇치 않다면 이전 테스크로 컨텍스트 스위치 합니다.

위에 이미 한번 설명한 내용입니다.

이 쓰레드에서 통용될수 있는 가장 핵심적인 단어는

응답성이네요... 쓰레드 답글 올라오는 속도도 빠르구요

윗분 인용하신책내용중에 첫번체 페러그렙은 제가 설명한 부분과 다르지 않은데

두번째 페러그렙은 제가 이 쓰레드에서 계속 해온 이야기와는 다른 이야기네요.

번역상의 문제인지 제 이해력이 부족한건지 모르겠습니다만..

실시간 프로세스를 제외하고 모든 유저프로세스는 커널 프로세스보다

우선순위가 낮습니다. 리눅스를 포함해서 대부분의 운영체제가 그렇쵸..

당연한 이야기 아닌가요?

그런데 커널모드에서 커널 프로세스 수행이 끝나지 않은 상황에서

일정 프리엠션 포인트마다 확인해서 유저프로세스로의 컨텍스트 스위치가 어떻게 일어날수 있다는건지 모르겠습니다.

그렇게 해서 얻을수 있는 이익도 없구요..

원칙적으로 인터럽트 수행이 밀리는것을 방지하기 위해서

프리엠션 포인트마다 인터럽트 수행여부를 확인하는것이 운영체제의

응답성 증대를 위한 페러다임에 부합하는 개념이라고 생각합니다.

더이상 이부분가지고 논쟁하고 싶지는 않구요..

윗분이 인용하신 두번째 페러그레프는 제가 잘못 이해한거라 생각하고 다른분들 판단에 맞기겠습니다.

본의 아니게 논쟁 비슷하게 되버렸는데요..

우리가 하는 일이 크게 보면 공대를 졸업해서 IT 관련업종에 종사하지만

모두가 다 똑같은 분야에서 메이저리티를 가지고 있는것은 아닙니다.

대학원 실험실에서도 그리고 지금 종사하는 회사의 연구소에서도..

수많은 사람이 있지만 다 서로 서로가 하는일이 다르고 잘하는 일이 다릅니다.

80여명정도 되는 작은규모의 연구소인데 서로가 서로 하는 일에 세미나라도

해주려 치면 크게 크게 넘어가지 않는한 세세하게 들어가면 이해시키기가 어려운 경우가 많습니다.

제가 커널 관련분야에 종사하다보니 하드웨어 하는 분들이나 제 윗단에서

작업 하는 분들하고 이야기 나눌때 답답한면이 많은데요..

물론 그분들도 저를 이해시키려고 힘들게 노력하십니다만...

가장 크게 문제가 되는게 책이나 문서를 보고 공부하는 경우와

소스코드를 분석하면서 공부를 하는 경우에서 오는 차이입니다.

누구나 자기의 주전공분야? 에서는 코드에 기초해서 공부하고 이해하고

내용을 만들어 나갑니다.

하지만 그 주변분야에 관해서는 책이나 문서로 채우지요..

잘못된 책이나 문서를 참조해서 문제가 되는 경우도 있겠지만

더 많은 경우에 책이나 문서를 만든사람의 뉘앙스와 그 책을 읽고 이해하는사람이 느끼는

뉘앙스가 다르다는 겁니다. 그런데도 불구하고 사람들은 문서와 책에서 본내용을 맹신 하거든요..

이쓰레드에 몇가지 잘못된 인용들이 그런 경우라고 생각합니다.

다행이 윗분이 인용하신 책은 용어사용이나 내용을 보아 좋은 책이라 생각됩니다만

그래도 역시 코드를 살펴보면서 이해하는것 하고는 다를수 있습니다.

물론 제가 모든운영체제의 소스코드를 다 외는것도 아니고 합니다만

이런 이야기를 하는 이유는 두가지 경우에 차이점이 분명이 있다는걸 말씀드리고자 함 입니다.

본의 아니게 남이 써놓은 이글 저글들에서 틀린 부분만 잔뜩 지적하고 갑니다만

서로 서로가 갖은 전문 지식을 서로나눈다는 본래 취지에서 크게 벗어난것은

아니니 너그러이 이해바랍니다.

"인터럽트는 발생 즉시 수행한다"

이런 문장 아마 수도 없이 많은책에 언급되어있을겁니다.

모두들 그렇게 믿죠.. 우상처럼...

그리고 그렇게 틀린말도 아닙니다.

하지만 개발자 입장에서 봤을때 저 말은 레절루션이 아주 낮은 상태에서만

맞는말이 됩니다.

보다 높은 레절루션에서 생각하면 저말은 아주 모호한 말이 됩니다.

전제가 아주 많이 붙어야 정확한 말이 되는거죠.

지금 잠시 언듯 생각해봐도 두세줄 이상 전제조건을 달아야만

정확한 표현이됩니다.

정확하게 이해하려면 특정 인터럽트 서비스 루틴을 콜하는 구문을 다 찾아서 살펴보면 됩니다.

좀 양은 많겠습니다만 여러가지 툴들을 이용하면 별로 어렵지 않게 찾을수 있습니다.

인터럽트 서비스 루틴이 무슨 전지전능한 신도 아니고 코드에서 콜하지 않았는데 수행될리 없습니다.

커널은 하드웨어를 쥐고 유저모드의 프로세스에 cpu 타임을 배정합니다.

인터럽트중에 비교적 우선순위가 높은 클럭인터럽트 수행을 (수정하지 않았다면 1/100초) 커널은 수행합니다.

클럭인터럽트 수행이후에 남는 CPU시간을 커널은 유저모드 프로세스에 할당합니다.

그런의미에서 인터럽트는 클럭인터럽트 발생주기보다 빠른 시간안에 반응 할수 없습니다..

여기에 사용되는 개념이 클럭인터럽트 레절루션입니다.

실시간 응답이 중요한 시스템에서는 클럭인터럽트 발생주기를 짧게해서

응답성을 높입니다.

CPU 성능에 따러서 다릅니다만 리눅스같이 덩치 큰 커널은 몇만분의 1초

이상 해상도를 높이면 클럽인터럽트를 오버헤드 때문에 시스템이 동작하지 않습니다.

클럭인터럽트를 수행하는 도중에 또 클럭인터럽트를 발생해야 하는 시점이 되서

결국 클럭인터럽트를 수행하지 못하고 까먹게 되는거죠..

덩치가 좀 작은 커널인 경우에는 수십만분의 1초 까지도 해상도를 높일수 있습니다.

그냥 제가 논문 쓰던때가 생각이 나서 끄적여 봅니다.

아참 그리고 이 이야기는

제 생각이 아니고, advanced operating system concepts에서 나온 이야기 입니다.

거시기 실바스까츠가 쓴 책말입니다.

정확히 인터럽트의 대기에 관해서는 언급이 없지만, 시스템 클록의 낮은 해상도는 명확히 문제삼고 있습니다.

정말 내공들이..^^; 많은걸 배우고 갑니다...

전 공부가 부족하지만 제가 알고있는건 sangwoo님 의견이랑 같긴 하네요..

또 약속을 깨고 다시 씁니다. 죄송합니다. (__)

제가 아는한 Interrupt-driven 하드웨어 (x86등)에서는
명시적으로 커널이 interrupt service routine을 call하지
않습니다. 다만, 부팅 초기에 interrupt handler를 설정해
둘 뿐이죠. 그리고 해당 하드웨어가 interrupt를 보내오면
CPU는 현재 컨텍스트에 transparent하게 interrupt
service routine으로 점프하는 걸로 알고 있습니다.
(interrupt handler와 interrupt service routine은 모두
같은 뜻입니다.)

??? 잘 이해가 안되는데, 그렇다면 clock interrupt 이외의
다른 interrupt들의 service routine은 clock interrupt
service routine에서 call한단 말씀이신가요?

만일 위의 내용이 사실이라면
1. 어째서 그게 인터럽트 메커니즘이겠습니까? polling이죠 :-)
2. Clock interrupt routine은 누가 call 해 줄 수 있을까요?
3. Interrupt masking에 의한 interrupt의 loss라는 개념
자체가 필요가 없어지지 않습니까? 어쨌든 모았다가
한번에 처리하면 되는데..

clock interrupt도 network이나 다른 device와 같은
인터럽트일 뿐입니다. timer device가 보내오는
(물론 interrupt priority는 매우 높고, device마다 다르죠.)

Clock interrupt resolution을 높임으로 해서 얻는 효과는
스케줄링을 더 자주 이루어지게 하는 것입니다. 물론
high-priority *procss*의 응답성이 높아지겠죠.
www.cs.princeton.edu/courses/archive/fall03/cs518/papers/clock.ps
를 보셔도 좋겠습니다. (google 만세!)
그러나 이것은 interrupt의 응답성을 높이는 것과는
상관이 없습니다.

참고로, clock interrupt resolution이 너무 높으면
시스템이 작동하지 않는 이유는, 더 낮은 priority의
interrupt service routine (네트워크나 ata 등등..)
의 interrupt를 실행할 시간이 없어지기 때문입니다.
계속해서 clock interrupt를 처리해야 하기 때문이죠.
interrupt driven arch의 숙명인 livelock으로 보시면
되겠습니다.

FreeBSD는 작년인가 재작년에 clock interrupt를 1000Hz
로 높였습니다. 펜티엄 I 200MHz 정도만 되어도
1000Hz로 작동시키는데 아무 문제가 없다고 하더군요.
(그 이전에는 말씀하신대로 100Hz였습니다.)
http://groups.google.co.kr/group/mailing.freebsd.hackers/browse_frm/thread/411fda864396da60/476105ade0153606?tvc=1#476105ade0153606
제 기억에는 위의 쓰레드 이후 얼마 지나지 않아서
-CURRENT에서 1000Hz가 기본값이 되었습니다.
Linux도 비슷한 관련글을 보긴 했었는데.. 출처는
기억이 잘 나질 않는군요. (확인해 보니 2.6으로 넘어오면서
1000Hz가 디폴트가 된 것 같습니다.)

뒷부분만 보고 서로 다른 용어가 일치하지 않은 듯 했는데... 앞 부분까지 봤더니 그게 아닌 듯 하군요...

인터럽트 벡터를 초기화 시켜놓고... 하드웨어 인터럽트 플래그를 세팅해놓은 것만으로... 인터럽트가 들어오는 즉시 인터럽트 벡터에서 해당 인터럽트를 처리하는 루틴(interrupt handler)의 주소를 찾아서 jmp 를 합니다... 끝나는 즉시 다시 원래 컨텍스트로 return 을 하구요... 프리엠션 포인트가 없더라도 억지로 인터럽트 플래그를 마스크하지 않는 이상은 충분히 인터럽트 핸들러를 call 하는 것이 가능합니다...

제가 그동안 공부하고 사용해봤던 마이크로 CPU 에서는 분명 저렇게 동작하고 있었고... x86 은 혹시나 다른가 해서 intel 의 x86 메뉴얼을 찾아봤습니다... 1권의 6-10 을 보면 인터럽트와 익셉션에 대한 설명이 나옵니다... 플래그가 마스크된 인터럽트가 아니라면야... 전지전능한 신이 맞는거 같습니다 :evil:

interrupt 는 I/O 에 의해 발생하는 것이고... exception 은 코드를 수행하다가 발생하는 것이라고 되어있군요 (trap 이라던가 devide by 0 등의 경우요)

상우님이 말하시는 인터럽트가 하드웨어 인터럽트라면 정확하게 일치하는군요... :)

인터럽트 핸들러가 일종의 시스템 콜이라기 보다... trap 등을 통해 인터럽트를 발생시키고... 호출할 시스템 콜 번호를 확인한후 시스템콜 벡터를 이용해서 원하는 시스템 콜을 수행하는 것이라고 알고 있습니다 ...

시스템 콜이나 인터럽트 처리 외에 커널 모드에서 코드가 수행되는 일이 어떤 게 있는지는 잘 모르겠군요...

(실제 코드를 보거나 작성해본 적은 없습니다만... 이론적으로 제가 아는 내용에 한해서 좀 이상한 부분이 있어서 답글달아봤습니다)

이야기가 프리엠티브 커널에서 인터럽트 처리로 넘어왔군요..

인터럽트가 바로 즉시 처리되는건 아니라는 제 말에 오류가 있었는지 모르겠습니다만...

제말을 검증할수 있는 분들이야.. 알아서 판단하실듯 하고..

이글을 읽을지도 모르는 몇몇 학생들의 이해를 돕기 위해서 간단한 글을 남깁니다.

단일cpu 에서 cpu 처리 흐름은 한개입니다.

단지 우리는 아주 짧은 시간으로 그 처리흐름을 나누어서 쓰니까 cpu가 동시에

여러가지 일을 하는듯 보입니다만...

물론 cpu 내부적으로야 파이프라이닝도 하고 그렇습니다만 그이야기 하는것 아니니까 그런쪽으로 딴지 걸진 말아주세요..

인터럽트 이야기로 다시 돌아가겠습니다.

cpu의 처리 흐름이 하나라는 가정해서 cpu의 처리속도에 한계가 있습니다.

빠르건 느리건 그렇습니다. 한계는 있는거지요..

그런데 인터럽트가 마구 발생합니다. 수십 수백 수천개의 인터럽트가 마구 발생하는 상황을 가정합시다.

이 모든 인터럽트 서비스 루틴이 때론 간단한일을 때론 복잡한 일을 수행합니다.

그런데 저 모든것이 실시간적으로 수행된다고 생각하시면 곤란합니다.

물론 목표는 그걸 목표로 합니다...

하지만 현실에 그걸 다 커버 할수 없는 상황이 있을수 있기 때문에

운영체제는 인터럽크 우선순위를 세부적으로 결정해 놓습니다.

살펴 본지가 오래되서 기억이 가물 가물 하지만

가장 우선순위가 높은것은 시스템이 따운되는 상황에서 처리해야 할 루틴들이고

그다음으로 클럭인터럽트 처리 루틴이고

맨 마지막에 소프트웨어 인터럽트들이 가장 낮은 우선순위로 배정됩니다.

예를들어 낮은 우선순위의 인터럽트를 처리한다 칩시다..

그순간 더 높은 인터럽트가 발생하면 해당 인터럽트 서비스루틴의 처리를 종료하지 않고

더 높은 우선순위의 인터럽트 서비스루틴을 처리합니다.

그리고 돌아오려면 돌아오는데 이때 또 더 높은 우선순위의 인터럽트가 계속

발생하면 낮은 우선순위의 인터럽트는 처리가 지연되고 밀려 있게 됩니다.

얼핏 보니 제가 사용한 시스템콜과 윗분들중에 몇분이 사용하신 시스템콜의

용어정의 범위가 다른듯 합니다.

제가 사용한 시스템콜이라 함은 리눅스 내부에 구현되어있는 함수들입니다.

다른분들은 저보다는 더 큰 의미로 시스템콜이라는 단어를 사용하시는데

제가 그걸 잘 모르고 있었던듯 합니다.

그리고 마지막으로 상우님이 글쓰신 말미에..

HZ 이야기를 하셨는데..

리눅스 내부적으로 클럭인터럽트 발생주기는

100*HZ/1000 인가 그렇습니다.

버전별로 바뀐적 없구요..

커널 컴파일할때 물론 수정가능합니다만 디폴트값이 버전별로 바뀐적은 없구요..

HZ는 CPU클럭이 아닌 아키텍처에 디펜던트한 상수입니다.

i386 은 1000 입니다.. 다른 종류의 cpu 들은 arch 폴더 및에 정의된 파일들이 있습니다.

스케쥴링 관련 글타래가 순식간에(연휴라 그런가??) 길어지는 군요.
정리겸, 저도 의견을 제시해봅니다.

분명히 하고 넘어가야 할 것은
일단 인터럽트는 선점형/비선점형 스케쥴링(또는 kernel preemption)의 개념과는 관련이 없고,
구현상에서 인터럽트 관련 수행이 달라지는 국소적 현상을 가지고 있을 뿐입니다.

일단 선점/비선점 스케쥴링은 모두 알고 계시듯이 "태스크의 흐름"을 시간에 따라 바꾸어 줍니다.
선점 스케쥴링은 태스크가 suspend 되는 시점, 즉, time_delay(or sem_wait, mutex_lock..)
이전에도 'time slice 또는 ISR 종료후' 스케쥴링 프로시저에 더 높은 우선순위의 태스크가 ready일때는
context switching을 수행합니다.
여기서 말하는 "태스크의 흐름"은 일반 프로시저와 시스템 콜이 시간적으로 혼합되어 있습니다.
비선점 커널 컴포넌트(선점과 비교해서 비선점 커널)에는 이러한 태스크들이 여러개들이 있을때
커널 컴포넌트로서 시스템 콜 수행중에 태스크간 스케쥴링이 막혀야 할 부분들이 있고,
이를 위한 한 방법으로 context switching을 수반하는 인터럽트 프로시저를
lock하는 방식이 사용되었습니다.(재진입 불가, 공유자원 보호)

일단 위의 방식으로 시스템 콜은 보호되었으나,
OS전체적으로 실시간성을 떨어트리는 원인이 되기 때문에(시스템 콜의 일부 수행도중 더 높은
우선순위의 작업을 할 수 없다 -> 응답시간은 실시간 시스템(주로 임베디드)에서 치명적입니다.),
시스템 콜 수행중에도 최대한 context switching가능하도록 선점형 커널이 고안된 것이고,
비선점형 커널보다 더많은 작업(재진입 가능등..)이 되어있는 시스템이 되겠지요.

헉, Q/A코너에 있는 걸 읽기 시작했는데, 어줍잖게 글 달아보려고 새창에서 열었더니 어느새 이곳으로 이동되었네요.
잘못 이해하고 껴들지나 말아야 할텐데, 아 살떨~^^;
음. preemptive하다는 것에 대한 정의때문에 주제넘게 껴듭니다.
제가 알고 있는 내용을 검증하기 위한 용도일 뿐이니 너무 괴념치들 마시길^^;

priority 정책은 기본적으로 상위 우선이 됩니다.
상황은 높은 우선순위의 작업이 수행되고 나서 스케줄링에 의해 낮은 우선순위의 작업이 수행중에 있습니다. 이때 다시 높은 우선순위의 task가 정상적으로 수행중인 낮은 순위 task를 제치고 자기 일을 볼 때, preemptive하다고 하는 것으로 알고 있습니다.

interrupt resolution과 관련한 immediate 처리 여부가 잠시 논의되었지만, interrupt처리는 즉시 처리될수도 있고 pending될수도 있다고 하는 편이 맞습니다.
굳이 polling스럽게 몰아서 처리한다는 것이 아니라, nesting, masking이 존재한다는 것입니다.
이때 preemption특성과 관련이 있는것은 nesting입니다.
낮은순위 interrupt가 assert되어 해당 ISR이 처리되는 중간에 높은순위 int가 치고들어왔을때 낮은순위 isr이 pending는 상황을 nesting되었다고 하고, 그렇게 nesting가능한 구조가 preemptive하다고 하는 것으로 알고 있습니다.

정리하면 연장자가 언제든지 새치기가능하면 preemptive하다. :D

저는 커널에 관련된 코딩을 해보진 않았지만..
이 쓰레드의 수많은 글타래들을 읽어보니 windows도 리눅스와 거의 비슷한 로직으로 구현된 듯 해서얼마전 공부한
windows의 선점형 스케줄링부분에서 몇자 발췌해 봤습니다..

IRQL (Interrept Request Level) : 윈도에서 정한 논리적의미의 하드웨어적 우선순위
// 하드웨어적인 우선순위
31 [ High]
30 [Power failure]
29 [프로세서간의 인터럽트]
28 [ Clock]
27 [프로파일]
26
| [device]
3
// 소프트웨어적인 우선순위
2 [ DPC/dispatch] // 커널(?)
1 [ APC]
0 [Passive] //유저 level

윈도에서는 타이머 인터럽트가 발생되면(Clock level) 현제 쓰레드의 퀀텀(CPU사용을 위해 할당된 양)값을 3감소시키고
만약 0보다 작아지면 스케줄링을 위한 루틴을 DPC큐에 넣게 되고 모든 하드웨어적 인터럽트 루틴이 끝난 뒤
DPC큐에 포함되어진 루틴들이 하나씩 수행되어 진다.(DCP level)

언제나 우선순위가 높은 인터럽트가 모두 수행된 후에 낮은 인터럽트가 수행 될 수 있는 것에서 미루어 볼때..

쓰레드에 대한 스케줄링 및 다른 쓰레드로의 스위칭을 위한 초기화 작업은 DPC level에서 이루어 지는데,
이는 실행되고 있는 쓰레드가 DPC level보다 아래에 있을 때에만 쓰레드의 스위칭이 가능하다는 이야기가 되기도 한다.

...........
뭐 대충 이런 내용이 있군요..

CPU의 인터럽트 플래그가 enable되어 있는 동안에는 하드웨어적인 인터럽트는 항상 우선적으로 처리되어지고..
스케줄링에 관련된 루틴은 그 다음에 이루어지며..
스케줄링 루틴이 실행될때 프로세스나 쓰레드들에 대해 스케줄링이 가능하다 라는 의미가 되겠군요...
(스케줄링 우선순위 큐는 IRQL과는 무관하며 서로 다른것임)

이 내용들이 windows에 대한 내용이라도 리눅스와 그리 다르지는 않을 것이라 생각됩니다..
(운영체제의 기본 concept으로 보면 당연한일일지도)

현대적인 운영체제... 즉, 인터럽트가 끌고가는 현재 컴터 구조하에서만
발생할 수 있는 문제가 선점과 비선점 커널의 문제 아니던가요?
인터럽트가 없는데 과연 선점이 가능한지, 또는 선점, 비선점의 구분이 필요한 지에 대해서는..... :shock:

즉, 인터럽트의 시점 및 대기 유무가 예측가능하다면, 애당초 선점, 비선점에 대한 고려조차도 필요 조차가 없겠지요...

제 생각에는 커널의 선점, 비선점에 대한 논의는 곧 인터럽트(이하 하드웨어 인터럽트)의 대기 여부를 논하는 문제로 동등하게 환원된다고 생각합니다. 위에 mach님께서 설명해주셨듯이 핸들러 역시 자료구조이며 로직에 불과하니까요(로킹이 가능하며 언제든지 비일관적인 상태에 놓일 수 있는...)... :?

물론 몇몇 패닉 수준의 이벤트를 알리는(또는 지시하는) 인터럽트라면,
그 다음의 작업의 순차열 및 일관성에 관심을 두지 않으므로 논의할 필요가 없겠지요...
이러한 경우에 한해서는 즉시(아무 생각없이, 그냥 막무가내로, 플래그 유무로만 판단하고) 인터럽트가 처리된다는 표현이 크게 이상하지 않은것 같습니다.

그 이외의 경우, 즉 작업의 순서(타이밍)나 커널 자료의 일관성을 유지하면서 정상적인 처리가 필요한 경우,
과연 인터럽트가 즉시 실행될 수 있는가는 상당히 중요한 문제라고 생각합니다.

특히, 이를 단순히 로킹 또는 인터럽트 마스킹(또는 ipl 포함)을 이용해서 처리하고자 했던 것이 이제 슬슬 문제시되는 환경(다중 처리기)으로 바뀌어가는 추세이므로 인터럽트의 대기 문제가 좀 더 정확히 이해가 안된다고 해야하나.. 무어라고 해야...중얼중얼...

흐흐흐... 궁금한게 있어서 질문을 남기려다 말이 길어져서리... 그만..
이 스레드를 읽은 다른 어떤 녀석과 기나긴 대화로 티격태격하다가 그만, 둘 사이의 근본적인 차이에 눈을 뜨게 되었습니다.
즉, 인터럽트 사이클로 빠지기전에 명령어가 몇 개나 진행하느냐는 문제였습니다.
저는 페취 사이클, 익스큐션 사이클이 적절한 타이밍 설정으로 인해 또한 적당히 반복하다가, 즉 조금 많은 명령을 실행하다가 특정 시점(설정한)이 되면 인터럽트 사이클로 빠진다고 알고 있었습니다만, 그 분(?)께서는 명령어 하나 페취 - 익스큐션 - 인터럽트의 각 사이클이 반복된다고 주장합니다.

흐음...
페취 사이클과 익스큐션 사이클은 정녕 단 하나의 명령어만 실행하고 인터럽트 사이클로 빠지는지...........
궁금증 좀 해결해 주셨으믄...... 합니다...

현재 제가 접근 가능한(?) 웬만한 참고서에는 전부 단일 명령어 페치-실행-인터럽트 사이클로 묘사되어 있네요....
이론이론....쩝....
아닌거 같은데....

음 , 이 경우에는 외부요인에 의한 인터럽트보다는 CPU내부적인 인터럽트로 얘기를 풀어가는게 좋겠습니다.

*한번에 여러개 명령을 실행하고, 인터럽트 사이클로 간다면,
0으로 나눈경우(DIV명령), 오버플로우(ADD명령)등은 즉시 검사하지 않고, 명령어 몇개 더해보고 하겠다는 얘기로도 통하는데......

* 혹시나, 다수명령후 인터럽트 사이클을 수행하게 CPU를 만들었다고 가정할때, CPU는 부가적으로 몇개(?) 중 어느 명령이 인터럽트를 유발했는지, 아니면 복합적으로 발생했는지? 아니면 외부요인인지? 를 알아내는 방법이 필요할 것입니다.

*따라서, 매 명령어 수행마다(fetch, indirect, execute, interrupt) 인터럽트 사이클은 준수되어야 할 것입니다.

ed 군님 말씀 잘들었습니다.

그런데 한가지 좀더 명확했으면 하는 부분이 있어서 이렇게 글을

올립니다.

요기 위해서, 그리곤 "말미엔" 바로 여기 말미엔의 의미가,

nested되었떤 모든 인터럽트의 수행을 마치고, scheduler가 호

출이 된다는 말씀이신가요??? 커널 모드 선점형에서요?

흐, 낚이셨군녀^^;
전 사실 잘 이해가 되지 않습니다. 커널 space외에 선점이란 말이 쓰이는데가 있는지도 모릅니다. 쓰나요?
제가 적어본 글은 제가 저렇게 만들어서 쓰고 있다는 거지, 저게 정석이란 말이 아닙니다. 하긴 일반론적으로는 맞는 말 아니겠습니까?
그러니 언급하신 말미에 scheduler를 호출하건, process queue를 scramble하건, lookup table entry를 박살내건 그건 만드는 사람 맘인거지 어때야 한다는 공식이란건 없다는 겁니다.

윗분께서 말씀하신대로 이론적인 부분에서 저는 상우님 의견에 동의합니다. 그걸로 되었다고 생각해서 괜시리 끼어들지 않으려고 하다가 자꾸 이야기가 지엽적이고 피상적으로 흐르는것 같아서 이렇게 생각하는 넘도 있다는 정도, 혹은 대애충 만들어 써도 대충 그냥 돌고 쓸만하니 책 내용가지고 넘 얽매이지 않는게 좋지 않겠냐는 어줍지않은 어중이가 되본겁니다.

그렇다고 이런 논쟁이 무가치하다고 생각하지는 결코 않기 때문에,
소모적인 논쟁인양의 뉘앙스가 느껴지는듯하게 적으신 윗분의 말씀은 서운스럽긴하네요. 뭐 이렇게 생각하는 사람도 있고 저렇게 생각하는 사람도 있으니깐...

고꼬마데!

에... 좀 이해가 안되서 anfl님이 이 글타래에 남기신 다른 글들을 우선 읽어보았습니다. 또 괜한 뻘소리하면 안되니깐녀^^; (이미 했나?ㅎㅎ )

irq nesting은 반드시 우선적으로 완료해야할 기본과제가 아니었던가요? nesting이 가능한 구조로 만들어야 한다는 것과 nesting된뒤에 딴짓하다 unnesting하는것과는 큰 차이가 있습니다. 아니 만든사람 맘인거 맞지만 그렇게 만들면 irq뒷감당이 안되게되고 맙니다.
irq nesting은 irq끼리의 preemption을 이야기하는거지, irq아닌 다른 kernel code와 비교하면 무조건 isr이 우선순위가 높습니다.
그러므로 context switching은 nesting된 isr을 모두 수행완료하고 하는것이 옳다고 봅니다.

scheduler를 isr에서 호출할수 없는 상황이라...
irq stack을 task stack에서 처리한다고요? 글쎄요, 전 한번도 그런걸 본적도 그렇게 만들어본적도 없어서 속단은 어렵겠습니다만, 그런 경우도 있습니까?
게다가 그게 왜 isr처리에 clock이 많이 소모된다는건지 설명부탁드립니다. 논리상으로는 task stack을 쓰던(정말?ㅡ.ㅡ; ) irq_stack을 쓰던 stacking하는작업은 동일할텐데요?

isr내에서 scheduler호출이 가능하게 되려면 선점형 kernel이란 전제조건이 있어야 가능하다... 라는 님의 말씀에 헉. 이건 무슨 뜻이지? 했더랬습니다. 이전 님의 글을 읽어보니 선점형 커널이란 재진입가능한 코드로 새로 짠 코드다라고 하셨더군요. reentrancy가 preemption을 가늠하는 잣대다? 전 동의할수없습니다.
scheduler가 isr이 되었던 isr중의 하나인 tick에 의해서건 call되는 건 OS의 기본입니다. 선점성은 이미 irq nesting, context switching시의 task rescheduling으로 확보되는 특성인것입니다.

task들의 atomic한 요소가 파괴되지 않게 설계된 커널. 이것도 이상합니다. 그건 비선점형 kernel에서도 동일하게 요구되는 사항이니까요.
그래서 이부분, 비선점형 kernel이 보호해주지 않는다는건 말이 안됩니다.

그리고 요기, 그렇기 때문에 비선점형 kernel에서는 precess의 자발적 양보없이 kernel이 강제적으로 task를 바꾸는 일은 불가능하게 됩니다. (물론 kernel 모드에서 말이죠.)
이해가 잘... 이미 kernel space에서 말씀하고 계신중에 kernel이 task를 바꾸는 일이 불가능하게 된다구요? 그 kernel이란건 대체 뭔가요?
scheduler를 말씀하신거겠죠?

두서없이 또 주절거려봤습니다.
건전한 논쟁(처럼 보이게끔 하면서 수다떠는 놀이)문화의 창달을 위해 우리 모두 열심히 달려 봅시다. :D :D :D :D :D

한번쯤 만들어 본듯하니깐 부연 설명없이 바로 설명하도록 하겠습니다.

네. 만드는 사람 마음이지만 ISR 내에서 scheduler를 호출하게 되면 뒷 감당이 안되는건 분명하죠.
그래서 저 역시 좋지 않은 방법이라고 말했습니다. clock cycle은 뒷부분에서 다시 언급하였으니 나중에 이야기 하기로하고...

정석대로라면 ISR > call back > kernel code 순서로 우선순위를 가지고 있지요. 교과서에도 그렇게 나와있고요.
그렇지만 이건 정책상의 문제이지 "무조건 ISR이 우선순위가 높다." 라고 말할 개재는 안됩니다. 정책이 바뀌면 바뀔수도 있는 부분이니까요.

그런 경우가 있습니다. 아직 한번도 안보셨나 보신데...
IRQ 처리 모델은 여러가지가 있습니다. 그중에 stack과 관련된 모델도 여러가지가 존재하는데 그중에 하나가 task의 stack에서 ISR을 처리하는 방식도 있습니다.

한번 IRQ 처리 관련 문서와 논문을 잘~ 찾아 보시기 바랍니다.

이럴경우 아키텍쳐마다 틀리지만 ARM 아키텍쳐에서의 장점은 구현이 쉽다는것과 IRQ 처리 모델이 단순해 진다는것, common ISR에서 stack change를 위한 instruction이 몇개 빠질수 있다는것이 있죠.
단점으로는 각 task에 stack을 할당할때 ISR 처리를 위한 추가 용량을 고려해서 설계해야된다는 문제가 발생하지요.

만들어 보시지 않았다면 한번 만들어보시기 바랍니다. common ISR 부분만 처리하면 되는데 그렇게 어렵지 않다고 말씀드리고 싶네요.

제가 말한것은 ISR 내에서 scheduler를 호출할 경우를 말한겁니다. 최대한 빨리 수행을 끝마쳐야되는 ISR에서 scheduler를 호출하면 당연히 clock cycle을 많이 소비를하지요.
특히나 common ISR의 경우 interrupt latency를 어떻게든 한 cycle라도 줄일려고 pipe line의 스톨까지 고려하는데 ISR 내부에서 scheduler를 호출하면 당연히 무리가 따르지요.
물론 이미 해당 IRQ의 ISR이 호출된 상황이기 때문에 interrupt latency와는 직접적인 관련이 없더라도 ISR은 최대한 빨리 수행되어야 한다는 대전재를 위배하는 것이니깐요.
그래서 좋지 않은 방법이라고 이야기 한겁니다.

제대로 안 읽어 보셨나보네요.
일단 먼저 ISR 내에서 scheduler 호출은 당연히 선점형 kernel에서만 가능하다는것에는 동의 하실겁니다.
그전에 그러한 모델을 경험해보시지 않으셨기 때문에 아마 이해하기가 힘드셨나 봅니다.
그리고 저는 분명히 선점 가능한 kernel의 요건을 "선점 가능한 코드"로 구현 되어 있을때임을 대전재로 명시했습니다. "선점 가능한 코드"의 요소중에 하나가 reentrancy이구요.
이렇게 "선점 가능한 코드"로 구현이 되어 있어야 irq nesting, context switching시의 task rescheduling이 확보되지 않겠습니까? :D

비 선점형 kernel에서는 rescheduling을 없앰으로써 kernel code에서 task들의 atomic을 보호하지요. 안그런가요? :twisted:

이렇게 받이들이는거에 대해서 충분히 이해합니다. kernel mode, user mode로 나누어진 kernel의 관점에서만 보시니깐 그렇게 생각하시는 겁니다.
많은 RTOS들은 user mode가 존재하지 않고 kernel mode에서만 동작을 하죠.

이해하기 쉽게 예를 들어보죠.
kernel mode만 존재하는 RTOS에서 task가 수행중에 kernel의 API를 호출했습니다. 그러면 kernel API 코드가 수행되겠죠.
이 수행 흐름은 task의 수행 흐름일까요? 아니면 kernel의 수행 흐름일까요?
어떻게 보느냐 관점에 따라 틀리겠지만 task의 수행 흐름이라고 보는것이 맞을껍니다.

그러면 kernel API 내부에서 scheduler를 호출했습니다. 그러면 이러한 호출은 task가 schedule yield를 자신의 코드 내에서 명시적으로 호출하지 않았더라도 자발적으로 양보한것이라고 볼수가 있죠.

그러면 이러한 관점에서 user mode와 kernel mode가 있는 kernel에서 task가 호출한 kernel API에 의해 kernel mode에서 scheduler가 호출된다면 이것 또한 당연히 task가 자발적으로 양보했다고 보아야 옳습니다.
kernel mode에서 수행중인 task의 job 처리를 위한 code에서 호출한것이니
깐요. 안그런가요? :twisted: :twisted: :twisted: :twisted:

후후. 누가 먼저 고압적인 자세를 취했는지 모르겠네요.

님의 글 다음으로 부연 설명한 제 글에 제대로 이해 못하시고

라는 표현을 쓰신건 님이 아니신가요?
저라면 서로 조심스러운 입장에서 저러한 표현은 자제를 했을 겁니다.
아무리 상대방이 내가 아는 지식과 틀린것 같더라도 조금은 조심해서 물어 보았을 거라는 생각이드네요.

각설하고... 이 글타래가 소모적인 논쟁으로 끝나지 않기 위해서 님께서 지적하신것에 대해서 답변드리겠습니다.

아키텍쳐 마다 틀리지만 task stack에서 IRQ를 처리하는 방식은 위험하지도 난이도의 복잡성도 높지 않습니다. 오히려 구조가 심플해지죠.
또한 ISR 내부에서 context switch 자유로움이 주어져서 ISR에서 scheduler를 호출하는 엄청난 일을 저지르는 겁없는 device driver 개발자의 실수도 용납이 가능하죠.

이러한것은 ISR top에서 중요한 일을 먼저 끝내고 또한 scheduler를 호출하기전에 interrupt를 enable하여 nesting 가능하게 했다는 전제하에서는 아무른 문제가 없습니다.

새로운 interrupt도 뜰수 있는 상태고 scheduler에 의해 수행될 task는 interrupt를 받은 task이거나 아니면 ISR에서 create한 interrupt를 받은 task보다 높은 priority의 task일거니깐요.

다만 문제는 모든 task에 stack을 할당할때 IRQ 처리를 위한 stack까지 할당함으로써 메모리 낭비를 가져올수 있다는것이 문제이지요.

무엇이 위험한지 구체적으로 이야기 해주시겠습니까? :twisted:
전혀 위험하지 않습니다. 어떤식으로 작성하느냐에 따라 장점이 될수도 있고 단점이 될수도 있는 상황이지만 위험한 상황은 될수가 없습니다.
아... 전혀 모르는 사람이 짜는건 위험한 상황이 될수도 있겠네요. 그러나 그건 kernel 관련 code 작성에서 어떠한 경우든 마찬가지이지 않습니까? :twisted:

reentrancy에 대해서 모를 분도 아니고...
때로는 밋밋하게 끝나는것도 여운을 남기는 운치가 있지 않겠습니까?

님과 이렇게 on line상에서 만난걸 행운으로 생각하고 또 이런 식으로 만난걸 유감으로 생각합니다.
다음에 기회가 있으면 같이 많은 이야기를 나누었으면 합니다.

그럼 좋은 주말되시기 바랍니다.

네, 우선 앞서 지적해주신 제 표현상의 부분을 사과드리겠습니다. 다만 그건, anfl님의 말씀을 폄하하는 의미를 담아 빗겨가는듯하게 드러낸게 아니라 제 속생각. 이를테면 스스로 반문한달지 하는 식의 것을 적어놓는 그런 버릇일 뿐이었습니다.
하지만 그것자체가 님께 고압적(헉... : 이럴때 씁니다. :D )으로 비쳐질수도 있다는 점을 간과했습니다. 좀 재밌게 써보자는 생각으로 덜 딱딱하게 쓰고싶다는 의도였습니다만, 앞으로는 조심하도록 하겠습니다.(_._);;

anfl님과 sangwoo님 덕분에 많은 것을 배울수 있었습니다. 처음 이 글타래는 명예의 전당으로 옮겨지기 전쯤에 이미 일단락되어보여 끼어들기가 꺼려졌었더랬는데, 선점에 대한 개념이 제가 알고 있는 바와 좀 다르게 가고 있는것 같아 주제넘게 끼어들었던 것입니다. 그러니까, 제가 이해하고 있는 선점성이란 글자그대로 새치기라는 개념인거고, 그게 가능하도록 만들어진 OS면 선점형이란 칭호를 붙여도 된다는 말이었습니다. 뭐랄까 개념이 엄청 쉽다고나 할까요? :D

그 뒤에 나온 task stack부분은 정말이지 제가 전혀 몰랐던 부분이었습니다. irq stack이 아닌 task stack을 쓴다니... 그런데 sangwoo님의 bsd kernel에 대한 설명부분을 보고는 아~ 그렇게 쓰기도 하는구나라는 사실을 알았습니다. bsd kernel을 언제고 공부해보고싶다는 생각도 들었구요. :D

아뭏든 참여한 보람이 있는 좋은 글타래였습니다. 두분 모두 감사합니다. :D :D :D