현재 위치

홈 ›› 블로그 ›› geekforum의 블로그

시스템 설계모델 - threaded? monolithic?

geekforum의 이미지
글쓴이: geekforum / 작성시간: 토, 2002/02/16 - 2:06오전

최근들어 회사에서 프로젝트를 진행하면서 겪은 일입니다. 프로젝트는 realtime OS에서 작동하는 일련의 통신용 프로토콜 스택을 만드는 일이었습니다. 물론, 타겟이 되는 프로세서는 embedded용 컨트롤러나 작은 마이크로 프로세서입니다. 타겟 프로세서에는 realtime OS가 존재합니다.

제작하고 있는 시스템의 구조를 스레드(혹은 task) 기반의 시스템으로 할 것인지, 혹은, monolithic(정확한 표현인지 모르겠습니다)한 시스템으로 디자인 할 것인지 고민을 하게 되었습니다.

여러개의 task로 시스템을 구성했을 경우, task들 간의 동기화와 통신, shared data의 protection 등 신경쓸 일이 많았습니다. 그리고, task 들 간의 scheduling 에 소모되는 overhead 또한 신경이 쓰였습니다.

반면, monolithic하게 시스템을 디자인 했을 경우 (여러개의 task로 구성된 시스템을 구성했을 경우의 각 task가 하는 일을 library function call을 하듯이 구현하는 경우) 에는, 발생한 이벤트에 대한 처리를 시작하여서 output까지 단 하나의 실행흐름으로 모든 것을 하게 됩니다. 연속적으로 이벤트가 발생할 경우 먼저 발생한 이벤트에 대한 처리를 하는 동안 계속 일어나는 이벤트들을 모두 처리할 정도의 프로세서 성능이 된다면 별로 걱정할 필요는 없겠습니다만, 아슬아슬할 정도의 성능을 가진 프로세서를 사용한다면 걱정이 아니될 수 없는 상황입니다.

어떤 방식으로 시스템을 구성하는것이 좋으냐 라는 문제의 결정은, 물론, 개발자 각자가 하는 것입니다만, 언급했던 두가지 모델의 장.단점에 대해 보다 여러사람의 의견과 지식을 들어보고 싶습니다. (마치, 운영체제 설계에 있어서의 쟁점과 비슷하네요)

댓글

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 월, 2002/02/25 - 11:27오전

RTOS는 구조적인 측면에서 두 가지로 분류할 수 있습니다.

하나는 Multi Thread 모델이며, 다른 하나는 Multi Process 모델입니다.

Multi Thread 모델은 OS 커널과 Application이 합쳐져서 서로의 구분이 없는 하나의 큰 프로그램이 되어 작동하는 구조로서, 공통의 작업 영역(Memory)을 자유롭게 액세스 할 수 있습니다. OS의 크기가 작고, 비교적 작은 크기의 시스템에서 구현이 쉽고 빠르다는 장점이 있지만, 커널과 Application이 하나의 프로그램으로 동작하기 때문에 사소한 Bug가 시스템 전체를 파괴하는 단점이 있습니다.

Multi Process 모델은 OS 커널이나 각 Application들이 모두 독립적인 프로그램으로 동작하도록 설계되어 있습니다. 각 Application은 서로의 Memory가 보호되어 있기 때문에 모듈 단위의 Application 개발이나 모듈(기능)의 추가, 변경이 쉽고 안정된 시스템의 개발이 가능하기 때문에 대규모의 시스템 개발에 용이합니다. 그러나 RTOS의 크기가 Multi Thread 모델에 비해 크기 때문에 작은 시스템의 개발에는 오히려 부담이 되는 단점이 있습니다.

RTOS의 두 가지 모델이 가진 서로의 장,단점을 고려하여 비교적 작고, 복잡하지 않은 기능의 시스템 개발에는 Multi Thread 모델을 사용하고, 의료기기와 같은 대규모의 복잡한 시스템 개발에는 Multi Process 모델의 RTOS를 사용하는 것이 좋다고 알려져 있습니다.

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 화, 2002/02/19 - 8:57오후

RTOS라면 역시 Monolithic이 낫지 않을까요-
RTOS라면 RTOS라면...

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 화, 2002/02/19 - 10:05오후

그런 고정관념을 깬 RTOS가 있죠: QNX

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 화, 2002/02/19 - 4:37오후

와 여기 글 올리시는 분들은 직업이 어케 되세요?
저같은 초보가 보기엔 정말 리누스 토발즈 처럼
위대해 보이십니다 +_+
전산 전공에 대학원 출신이신가요?
아직 진로를 정하지 못한 학생인데
고수님들의 배경이나 발자취가 궁금합니다

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 화, 2002/02/19 - 11:11오후

말빨 프로그래머, 실제로 커널 다룰 수 있는 사람 별로 없어요.

bsheep의 이미지

글쓴이: bsheep / 작성시간: 월, 2002/02/18 - 12:25오후

관건은 Thread 관리에 가는 overhead가 많다는 것인데..
요즘 컴퓨터는 왠간히 많지 않아선 그 overhead를 포함해서도 효과적인데..

embedded같은 경우는 하드웨어 사양이 높지 않을테니
얼마나 많은 여파를 끼치나 궁금하군요. ^^

OS가 Thread를 지원하면 사용하는게 프로그래머로썬
편하겠지만, 지원안한다고 Thread를 만들으면서까지
프로그램밍할 정도로 이득을 가져다주는 것은 없을것
같은데요. 어플마다 틀리겠지만.. RTOS이면.. Thread가
많으면 벌써 원래 의도했던 것에 벗어나는 디자인
아닌가요?

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 월, 2002/02/18 - 11:59오전

모놀리딕 커널과 마이크로 커널에 대한 타넨바움 교수와 토발즈, 그밖의 여러 사람들의 토론 내용입니다.

http://www.hanbitbook.co.kr/ebook/download.php?ebook_id=E001213-0059

bsheep의 이미지

글쓴이: bsheep / 작성시간: 월, 2002/02/18 - 12:17오후

아..
커널 모듈이 아니라 마이크로 커널이쥐.. ^^햐햐햐..
벌써 배우는것보다 잊는게 많는것 같네요.

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 월, 2002/02/18 - 12:45오후

핫.. 마이크로 커널입니다...
정말.. 배우는것보다 잊는게 더 많은것 같군요 ㅡ.ㅜ

정규현의 이미지

글쓴이: 정규현 / 작성시간: 월, 2002/02/18 - 9:27오전

글 올리신 분께서 먼저 이 사항에 대한 명확한 답변이
필요할것 같습니다.

1. 질문하고자 하시는 사항이 OS 커널모델에 대한
것인지 아니면 RTOS상에서 프로세스모델에 대해
질문하시는 것인지가 명확하지 않습니다.
- OS커널모델 :
- modulized : 커널및 기타필요기능을 모듈별로 분리
ex) Mach Unix ( 넥스트에 사용 )
- monolithic : 커널및 기타필요기능을 하나로 일체화
ex) Linux
- 프로세스모델 :
- 스레드 :
컨텍스트 스위칭 발생.
일반 OS에서 스레드를 생각하면 됨
- 테스크 :
컨텍스트 스위칭은 발생하지 않음.
인터럽트를 통해서 테스크 전환.
PC에서 인터럽트 콜 생각하면 됨

2. 질문에서 threaded냐? monolithic이냐고 하셨는데,
두 가지 용어는 전혀 비교될수 없는 성질의 것입니다.
threaded는 os의 프로세스 모델에 대한 용어고,
monolithic은 커널설계모델에 대한 용어입니다.

고로 질문하시는게 어느쪽인지 일단 명확하게 해주시기
바랍니다.

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 화, 2002/02/19 - 9:33오전

저기 질문이 있는데요

컨텍스트 스위칭은 뭔지 알겠는데, 태스크 스위칭이란 어떻게 다른건가요?

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 월, 2002/02/18 - 10:19오전

지적 감사드립니다.
OS 의 커널 설계모델에 대한 내용이라고 해 두고 싶군요.
다만, OS 의 커널 설계모델에 _만_ 한정된 답변들도 좋지만, 좀 더 범위를 넓게 잡은 답변들도 들어 보았으면 했었습니다.

제가 사용했던 용어에 문제가 좀 있었군요.
hurd 와 같은 mach 커널의 경우에 OS 의 기능을 일련의 ... (운영체제 서적에서는 '시스템 프로세스' 라고 하더군요) 시스템 프로세스들이 수행하지요. 굳이 변명을 하자면, RTOS 를 다루면서 thread 와 task 라는 말을 거의 구분없이 사용하는게 습관(!)이 되어서 그런 모양입니다 :(

다시한번 말씀드리면,
운영체제 커널 설계모델에 대한 답변들을 듣고 싶습니다.
여러가지로 배우고 생각할 점들이 많은 답변들을 들었으면 좋겠다는 바램입니다 :)

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 일, 2002/02/17 - 7:19오후

흐미,,, 짜고 고스톱 쳐라.......
글 흐름을 비슷한데........

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 일, 2002/02/17 - 4:15오전

제가 작은 프로젝트만 해서 그런지 모르겠지만 임베디드 컨트롤러를 쓰는 일이라면 쓰레드기반이면 배보다 배꼽이 더 커지지 않나요. 그냥 태스크를 세밀하게 나누고 인터럽트 소스 잘 정의해서 태스크 스위칭을 해가며 쓰는게 나으리란 생각이 드네요.

하긴 요즘 임베디드 컨트롤러는 하도 막강해서 별걸 다하긴 하지만 태스크 별로 context 관리하고 쓰레드별로 스택유지하고 하면 임베디드 시스템의 메모리로는 무리가 되지 않을까요. 뭣보다 개발하기도 골치아프고...^^;

bsheep의 이미지

글쓴이: bsheep / 작성시간: 일, 2002/02/17 - 11:27오전

embedded는 해본적이 없지만,,
windows CE가 아닌 경우(하드웨어가 뛰어나지 않은..)는
thread보다 이 분이 말씀하시는 것 처럼 task관리가
효과적인듯하네요. ^^

ps. 주제 제목이 조금 이상하네요. ^^
task 관리 vs thread 가 더 접근한거 같네요.
운영체제의 모듈화 vs monolithic은 별루 관계가 없는듯합니다.
monolithic해도 thread는 지원하거든요. 운영체제의 디자인을
가르키는 것이지, 운영방식을 가르키는 것이 아닌것입니다.

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 월, 2002/02/18 - 2:45오전

윗분의 질문은

소위 말하는 "프로세스"가 있도록 만들것이냐..
아니면 하나의 프로그램안에 모든것(OS,User App)을 넣는 구조로 만들것이냐
라는 질문으로 보입니다.
몇몇 Embeded OS에서는 Process같은걸 제공하지 않아서
사용자가 프로세스,쓰레드 관리부분을 만들거나 그냥 하나의 프로그램으로 다 만들거나 해야하는 경우가 있는데 그런 경우에 어떤 방법이 좋겠냐 하는 것을
물어보는 것 같습니다.
그래서 Monolithic에 ?가 붙는 것이겠지요.

혹시 제가 이해하고 있는 바가 틀릴 수도 있습니다.

개별 모듈을 만들고 유지보수 하는데는 Thread나 Process를 사용하는 것이
편리하겠지만....성능이나 코드에 들어가는 오버헤드는..조금 문제가 되겠네요.

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 토, 2002/02/16 - 6:21오후

머 적당히 베끼는 것 같은데요....
그냥 적당히 베끼세요.

영어단어 들어간다고,
허접을 빵구 때우진 못하죠.

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 일, 2002/02/17 - 9:39오전

꼭 이렇게 생각해야만 합니까?
비아냥 거리는것 같은 태도
결코 바람직 하게 느껴지지 않는군요!

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 토, 2002/02/16 - 8:18오후

왠지 속 시원한 얘기로 들리네요.
위에 글 쓰신분 남의 글 옮긴게 아니라면 조금더 구체적으로 쓰시는게...

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 토, 2002/02/16 - 8:36오후

그렇군요 ㅡㅡ^
글재주가 거의 없다시피 해서...
구체적으로 적었다고 생각했지만... 그렇지 못했던 모양이군요 ㅠㅠ

아래에도 좀 적었지만...
이야기를 듣고싶었던 주제는... 음...

실제 프로젝트에 관련된 얘기가 아니라, (물론, 처음 생각을 하게 된 계기는 프로젝트 때문이었습니다)

mach 커널처럼 모듈화된 시스템 (혹은 운영체제) 과 monolithic 하게 구성된 시스템 (운영체제) 과의 비교... 라고 해야 하나요?

그에 대한 주제로 얘기하고자 했습니다.
필연적으로 운영체제에 대한 얘기가 나오게 되는데, 꼭 운영체제에만 국한된 것만은 아니고, 어떤 시스템이든지 적용이 되는 범위로 이야기해 보았으면 합니다.

(제 생각 제대로 표현하기 정말 힘드네요 ㅡ.ㅜ 국어공부부터 해야할것 같습니다)

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 토, 2002/02/16 - 7:32오후

4가지 없는거 보다 허접이 낫죠..;)

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 토, 2002/02/16 - 5:56오후

음....
일단 지는 쑤레드와 태스크의 적당한 구별이 뭔지는 잘 모르지만 일반적으로 프로토콜 스택을 올리는 경우 realtimeOS에서 제공하는 여러 function을 이용하게 됩니다. 그 경우 지는 그걸 task라구 알구 있는데.....
글구 만일 stack의 사이즈가 매우 큰 경우라면 예를 들면 요즘 핸펀들은 스택이 매우 무겁지요. 제가 하구 있는 프로젝트만 하더라두 무려 70개 정도의 task를 가지고 동작합니다.(물론 CDMA는 다른 구조지만) 이 경우에는 task로 핸들링하는 구조를 만들되 realtimeOS와 일반 task엔터티 사이에 task entity를 핸들링하기 편하게 하기 위해 중간에 interface모듈을 두는 경우도 있읍니다. 이는 물론 다른 이유도 있어서 두는 거지만. 만일 없다면 TASK entity가 매우 복잡해 지겠죠?

하여간 진행하는 프로젝트의 성격이나 규모에 따라 적당한 모델을 선택하믄 되리라 생각됩니다. 물론 그 구조는 처음에 만들기는 힘들지만 나중에 다른 모듈을 필요에 의해 추가할때는 아주 편하겠지요.

P.S. 한가지 궁금사항
제가 embeded 관련된일만 해서 그런지 저는 쓰레드랑 task의 차이를 잘 모르겠더라구요. 그리구 전산전공두 아니구 해서.
윈도우에서 예를 들어 설명하믄 좀 알겠는데....그건 너무 약한거 같구. 뭔가 동작하는데 가진 data structure가 좀 다른가요. 자세히 설명해 주세요

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 토, 2002/02/16 - 8:06오후

그렇군요. 제가 구성한 시스템에선 다/행/히도 70 개씩이나 되는 태스크를 돌리거나 하지는 않습니다 :)
일반적으로 여러개의 태스크를 이용해서 모듈화시킨 시스템을 구성할 때엔 말씀하신 것처럼 -- arbiter 라고 해야 하나요? -- 중재 역할을 하는 태스크를 두어야 하겠죠. 그런데, 이처럼 모듈화된 시스템을 구성했을 경우, 단순히 모듈 -- 새로운 기능 -- 의 추가가 용이한 정도의 잇점밖에 없을까요. 전 그렇게 많이 알지 못해서 그것 말고는 생각되는게 없거든요 -_-;;

밑에서 노정민님이 말씀하셨지만, 일반적으로 embedded 시스템에서라면 할당된 작업을 계속 수행하는 여러개의 태스크들을 이용해서 시스템을 구성하지요 (역시, 제 머리에 떠오르는 가장 단순한 모델인것 같습니다) 그런데, embedded 이외의 분야들, 상용으로 사용되는 시스템(OS)들의 경우, monolithic 한 구성으로 시스템을 구성한 예가 많다고 들었습니다. 리눅스의 커널도 monolithic 커널이라고 하더군요.

이처럼 monolithic 한 시스템을 구성했을 경우, mach 와 같은 커널 (이건 일련의 job thread 들로 시스템이 구성되어 있다고 하더군요) 에 비해서 장점은 무엇인지, 또, 단점은 무엇인지 생각해 보고 싶었습니다. 그 반대의 경우에서의 장단점에 관해서도 이야기해 보고 싶었습니다.

갑자기, 제가 처음 글을 올렸을 때의 의도에 대해 다시 설명하는 이야기가 되어 버렸는데요... 써 주신 내용을 봐서, 역시, 작은 시스템에서는 다들 모듈화해서 시스템을 구성하는구나 하는 생각이 들었습니다.

사족으로...
저도 다른사람에게 설명할 정도는 못된다고 생각하지만, 일반적으로 '태스크' 라는 것은 realtime 시스템에서 주로 쓰이는 용어로써, '단위 작업을 처리하는 실행흐름' 이라고 알고 있구요, 쓰레드라는 것은, 보다 큰 운영체제를 이야기할 때 주로 쓰이는, '한 프로세스 내의 또다른 실행흐름' 이라는 것 정도의 차이가 있다고 알고 있습니다. 구체적인 자료구조는 자세히 모르겠습니다. process descriptor 내에 thread descriptor 와 link 가 있는것까진 일전에 본 기억이 납니다만. thread 를 lightweight process 라고도 부르더군요 -_-a

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 월, 2002/02/18 - 10:18오전

커널에서의 두 관점의 차이라면

모놀리딕 커널 -> 사람이 힘들다.
마이크로 커널 -> 컴퓨터가 힘들다.
정도겠죠.

그리고 일반적인 용어로 태스크==프로세스==job 입니다.
thread는 위의 것들보다 작은 단위죠.

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 월, 2002/02/18 - 3:42오후

태스크 == 프로세스라고 말할 수는 없습니다.
RTOS는 크게 두가지로 분류할 수 있습니다
multiprocess model에서 multitasking을 지원하는 OS(process 방식이라고 하죠)와 uniprocess model에서 multitasking을 지원하는 OS(흔히 thread 방식이라고 함).
vxworks, psos, ucos, vrtx 등은 후자에 해당함으로 task == thread가 더 적당한 의미가 됩니다.
전자의 process model의 OS는 잘 생각이 안나네요.(qnx가 이방식이던가..)
제가 주로 사용한 것이 vxworks와 ucos등의 thread 방식이라서...

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 월, 2002/02/18 - 7:08오후

제 생각에는 멀티 프로세스 vs 유니 프로세스방식 이란게..
CPU가 하나냐.. 하나 이상이냐..를 지칭하는걸로 보이는데..
제가 알기론 멀티 태스킹이란게.. 싱글 프로세서 시스템에선
멀티 프로그래밍의 개념(time slice를 각 task에 할당하여
동시에 task를 처리하는것처럼 하는기법)과 같거든요..
이게 실제로 task와 thread랑 어떤 관련이 있는지 궁금하네요..
단지 용어상 그렇게 구분을 하는것인지..
아니면 실제 모델자체가 다른건지..

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 월, 2002/02/18 - 3:52오후

언급하신 multiprocess model 과 uniprocess model 은 차이가 무엇인지요?
제가 알고있거나 다루어 본 RTOS 들은, 말씀하신 내용으로 볼 때 uniprocess model 인것 같습니다.

두가지 모델의 차이가.. 어디에서 기인하는 것인지요? 이해하기가(유추하기도) 좀 힘드네요 :)

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 화, 2002/02/19 - 9:29오전

제가 이해하기론..
multiprocess는 task들을 process, 즉 메모리가 보호되는 실행단위로 매핑하는거고
uniprocess는 task들을 thread, 즉 메모리가 보호되지 않는 실행단위로 매핑하는
그런 모델이 아닐까요
씨퓨가 하나/여러개를 말씀하시는것 같지는 않습니다.

안기현의 이미지

글쓴이: 안기현 / 작성시간: 수, 2002/02/20 - 10:10오전

저의 짧은 의견입니다. 틀린점이 있다면 꼭좀 피드백을 주시기바랍니다.

multiprocess와 uniprocess의 차이라

process는 program의 instance로 알고 있습니다.
(instance는 메모리에 적재된 program이죠.
붕어빵틀과 붕어빵으로 잘아실거라 생각됩니다.)

운영체제가 multiprocessing을 지원하면 프로세스 병렬(진정한 의미의 병렬은
아니지만 일단은..) 처리로 인한 peformance효과를 보는걸을 알 수 있습니다.
|----|
|---|
|----| 요런 그림많이 보셨죠?
대신 이렇게 운영체제가 이를 스케쥴링을 해줘야하는 overhead가 발생하죠.

그럼 운영체제가 uniprocess를 사용한다면? 프로세스 병렬 처리가 필요없으니
운영체제 설계자는 머리가 아플 필요가 없겠죠. 대신 성능 향싱을 위해선
program 개발자에게 그 Handling이 넘겨지겠죠.

보통은 운영체제는 하나니 운영체제 개발자가 고생하는게 옳겠죠.
uniprocess로 해놓고 그 운영체제에 모든 프로그램 개발자가 그런 레벨(?)까지
(언제부터인가 그런 레벨이 되어버렸음) 신경을 쓰는건 좀 고역이죠.

Uniprocess에선 Multi-Thread를 해서 나름대로 병렬 처리를 해야하고
MultiProcess는 해도 그만 안해도 그만일거 같습니다. (여기선 기본지식이 모자름)
이미 스케쥴링 되고 있는 프로세스를 또 멀티쓰레딩으로 처리하면
성능 향싱이 있는지 아니면 overhead로 역효과 인지는 잘모르겠습니다.

운영체제를 다중 프로세싱한다는 것은 프로세스를 다중 쓰레딩한다는 것과
같은 얘기라고 생각됩니다.

더 OS레벨에서 병렬처리를 하게하느냐(CPU가) Process레벨에서
병렬처리를 하게 하느냐의 차이인거 같습니다.

process는 메모리가 보호되는 실행단위고 (운영체게자 해줌으로 프로그래머는 memory-protection을 신경쓰지 않아도 됩니다.)
thread느 메모리가 보호되지 않는 일련의 흐름(그래서 safe-thread를 프로그래머가 해줘햐 하죠)

윗분의 말씀도 맞지만 운영체제의 멀티프로세스와 유니프로세스적용 결과론이지
두 단어의 직접적인 설명에는 조끔~ 아닐지도 싶습니다.

p.s 옛날 cpu 설계자가 cpu 명령어 셋이 많아 성능 저하가 된다고 대폭 줄였습니다.
그 후로 운영체제 커널 개발자의 밤샘이 많아졌다는 전설이....
누군가는 그 일을 해야하죠. trade-off의 세계에 살고 있으니 그래서 engineer가
재밌는 거구요.

antistar의 이미지

글쓴이: antistar / 작성시간: 화, 2008/07/29 - 1:32오후

위에 task entity에서 entity는 무얼 의미하나요? 구체적인 예를 들어주시면 감사

노정민의 이미지

글쓴이: 노정민 / 작성시간: 토, 2002/02/16 - 9:42오전

monolithic의 의미가 프로세스 하나로 전부처리한다는 것인가요? 그렇다면 여러 클라이언트가 동시에 서비스를 요구하는것을 처리하기가 어려울텐데요.

보통 프로토콜스택을 RTOS에서 동작하도록 설계할 때는 계층별로 TASK를 만듭니다. 프로토콜 수신단에 TASK하나, 인코딩 디코딩하는 TASK하나, 상위 응용프로그램과 통신하는 TASK하나, 타이머 TASK하나.. 그리고

그리고 각 TASK에는 IPC 수신을 위한 Queue가 하나씩 할당되구요... 무한 루프를 사용해서 Queue 처리를 합니다.

각 TASK에서는 상태관리를 하기 위해서, 상태 천이에 따른 TABLE을 만들고, Queue에서 메시지를 수신할 때마다 테이블 Lookup을 해서, 일을 하지요...

중요한 것은 일의 형태에 따라 어떤 TASK를 생성할 것인가와, 그 TASK에 따른 테이블 설계가 아닌가 싶네요..

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 토, 2002/02/16 - 10:01오전

엥? 태스크?
태스크 ---> 쓰레드로 쓰지 않나요?

댓글 달기

텍스트 포맷에 대한 자세한 정보

Filtered HTML

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

BBCode

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param>
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

Textile

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • You can use Textile markup to format text.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Markdown

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • Quick Tips:
    • Two or more spaces at a line's end = Line break
    • Double returns = Paragraph
    • *Single asterisks* or _single underscores_ = Emphasis
    • **Double** or __double__ = Strong
    • This is [a link](http://the.link.example.com "The optional title text")
    For complete details on the Markdown syntax, see the Markdown documentation and Markdown Extra documentation for tables, footnotes, and more.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Plain text

  • HTML 태그를 사용할 수 없습니다.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 줄과 단락은 자동으로 분리됩니다.
댓글 첨부 파일
이 댓글에 이미지나 파일을 업로드 합니다.
파일 크기는 8 MB보다 작아야 합니다.
허용할 파일 형식: txt pdf doc xls gif jpg jpeg mp3 png rar zip.
CAPTCHA
이것은 자동으로 스팸을 올리는 것을 막기 위해서 제공됩니다.