올려짐: 2003년1월23일 18:39 주제: 사용자 쓰레드와 커널 쓰레드인용:사용자 수준은 문맥교환의 오버해드가 없다, 문맥교환은 컨텍스트 전환(context switch)을 잘못 번역한 말입니다. 잘못된
용어로 이해를 하면 나중에 더 헷갈릴 우려가 있기 때문에… 사용자 쓰레드 방식이 커널 쓰레드보다 오버헤드가 적은(없지는 않음) 이유는
쓰레드간을 전환할 때마다 커널 스케줄러를 호출할 필요가 없기 때문입니다.
커널 스케줄러로 진입하려면 프로세서 모드를 사용자 모드에서 커널 모드로
전환해야 하는데, 이때 사용자쪽 하드웨어 레지스터를 전부 저장시키고, 커널
레지스터를 복구하고, 기타 등등…의 수많은 작업이 밑에서 일어납니다.
따라서 사용자 모드와 커널 모드를 많이 왔다갔다 할 수록 성능은 급격하게
떨어지는 것이죠. 사용자 쓰레드는 쓰레드 스케줄러가 사용자 모드에만 있기
때문에 그런 오버헤드는 발생하지 않습니다.인용:커널 수준은 사용자 수준 보다 효율적일 수 있다.. 그런데 사용자 쓰레드의 결정적인 단점은 프로세스내의 한 쓰레드가 커널로
진입하는 순간 나머지 쓰레드들도 전부 정지된다는 점입니다. 커널이 쓰레드의
존재를 알지 못하므로 불가피한 현상입니다. 쓰레드가 커널로 진입할 때는
write(), read(), …같은 시스템 호출을 부를 때인데, 시스템 호출 길이가
짧아서 바로 리턴할 때는 문제가 없지만 연산이 길어지면 상당한 문제가
됩니다. 전체 프로세스의 응답성이 확~ 떨어지죠.그리고 커널 쓰레드를 쓰면 멀티프로세서를 활용할 수 있다는 큰 장점이
있습니다. 사용자 쓰레드는 CPU가 아무리 많더라도 커널 모드에서 쓰레드
단위로 스케줄이 안되므로 각 CPU에 효율적으로 쓰레드를 배당할 수 없는
문제가 있습니다(프로세스 단위로만 배당이 되므로).그래서 리눅스, 윈도, 솔라리스를 비롯한 대부분의 운영체제는 사용자 쓰레드를
쓰지 않고 커널 쓰레드, 또는 커널/사용자 쓰레드 혼합 방식을 쓰는 추세입니다.인용:그리고 현재 리눅스에서는 두가지 쓰레드 모델이 모두 지원 되나요? 예, 모두 지원됩니다.쓰레드 방식은 크게 세가지가 있습니다. 이중 사용자 쓰레드는 요즘들어
리눅스에서는 별로 쓰는 사람이 없는 것 같고, 1-on-1 커널 쓰레드 방식인
glibc내의 LinuxThreads가 가장 널리 쓰입니다. 최근에는 이걸 더 발전시킨
NPTL(Native POSIX Threading Library)가 활발히 개발중에 있습니다.
커널/사용자 쓰레드 혼합 방식인 NGPT(Next Generation POSIX Threads)
도 IBM의 지원하에 최근 2.2.0까지 나와 있습니다. 둘간의 차이를 여기서
설명하기엔 좀 긴 것 같고, 전자가 후자보다 훨씬 간단한 반면, 후자의 성능이
전자보다 다소 높은 것으로 알려져 있습니다. 여담입니다만, NPTL이 처음
나왔을 때 우리 것이 NGPT보다도 성능이 훨씬 좋다고 자랑(?)을 했더니
NGPT팀이 자극을 받았나 봅니다. NGPT 홈페이지에 가면 새버전(2.2.0)
성능이 LinuxThreads는 물론 NPTL도 능가한다고 큼지막하게 써놨습니다.인용:kernel thread는 user thread에서 LWP 자료구조를 통해 연결되는데중요한 것은 아닙니다만…LWP는 경량 프로세스(lightweight process)의 준말로, 솔라리스에서(그리고
올려짐: 2003년1월23일 21:13 주제: 쓰레드 패키지 아케텍쳐참조 하세요. 이 글 쓰느라 시간 좀 들였습니다.Thread-Package Architectures는 크게 4가지가 있습니다. User-level threads, Kernel-level threads, multiplexed threads, kernel-supported user-level threads[User-level threads]User-Level threads는 응용 프로그램과 Link/Load가 되는 라이브러리로 구현되어집니다. 이 라이브러리에 동기화, 스케줄링 기능을 모두 담고 있습니다. 커널에서는 아무런 지원을 해주지 않으며, 커널이 보기에는 단지 그냥 Single process일뿐입니다. 프로세스마다 런타임 라이브러리의 Copy가 호출되므로 스케줄링 정책을 프로세스마다 달리 취할 수 있으며, 각 Thread마다 time quantum을 소모할 필요 없고, 런타임 라이브러리가 context를 유지하기때문에 switching을 할 필요가 없습니다. 그래서 User-Level Threads는 빠르고, 매우 효율적입니다. 그러나 장애가 꽤 있습니다.1. Blocking System Calls
Blocking function이란 처리가 완료되지않으면 return되지 않는 함수인데, 만약 특정 Thread에서 Blocking이 되어 버리면, 전체 process가 Blocking이 되어버립니다. 이런 이유로 운영체제가 제공하는 non-blocking 함수들만 사용해야 하며, 사용 빈도가 높은 함수(read,select,wait,…)들은 해당 함수의 non-blocking 버젼으로 대체해야할 필요가 있습니다.
2. Shared System Resources
동기화나 Locking없이 Thread끼리 공유하는 변수(드러나지 않고 감춰져 있는 경우)가 있을때, 그 Thread가 thread-safe하지 않으면 Overwrite되는 문제가 생길 수 있습니다. 이 이유로 사용할 함수는 재진입이 가능해야합니다. User-Level뿐만아니라 Kernel-Level 함수까지 모두.
3. signal Handling, Thread Scheduling
User-Level에서 이것을 구현하기란 상당히 어렵습니다. Timeslice를 다루기 위해 Hardware Clock 인터럽트를 보통의 방법으로는 받지 못합니다. 선점형(Preemptive) 스케줄링을 하기 위해서는 커널로 부터 Time Siganl을 받는 함수를 등록해두어야 하며, Timer Alarm Siganl을 다루는것은 다른 시그널을 다루는 것보다 아주 어럽습니다.
4. Multiprocess Utilization
하나의 프로세스에서 Time을 공유하고 있기때문에 여러개의 CPU를 동시에 사용할 수는 없습니다.정리 – 구현상의 어려움과 복잡성 그리고, 몇가지 장애에도 불구하고, concurrency와 efficiency의 이득을 가져다 줍니다.[Kernel-level threads]Kernel-level에 있는 Threads는 독립적으로 스케줄되므로 특정 Thread에서의 Blocking이 process로 전파되지 않습니다. 그래서 Blocking System Calls를 이용할수 있습니다. 또한 각 Threads끼리 Signal을 주고 받을 수 있습니다.
Kernel-level threads는 특별히 고려할만한 장애를 가지고 있지는 않습니다. 물론 마찬가지로 Thread-Safe해야 하지만, OS 개발자들은 대개의 표준 라이브러리를 Thread-Safe하게(재진입해도 문제없겠끔) 만들기에 User-level threads보다 통상적으로 보다덜 말썽을 피웁니다.Kernel-level threads는 안정성에 비해서 너무 느리다는게 큰 단점입니다. 바로 Thread Context-Switch 때문입니다. 마로비치의 연구에 의하면 10배정도 느리다고 합니다.
[multiplexed threads]
User-level threads와 Kernel-level threads를 섞은 방법입니다. User-level thread(줄여서 Thread)는 LWP(가벼워진 프로세스, Lightweight Processes)에 의해 multiplex됩니다. 커널은 LWP를 스케줄링/실행하고, LWP는 대기중인 thread를 골라서 실행합니다. thread는 하나의 LWP에서 실행이 되어지며, Time slice가 바뀔때 LWP도 바뀌어질 수 있습니다. 프로그래머는 thread를 사용할 수도 있고, LWP를 직접 사용할수 있고, 둘 모두를 동시에 사용할 수도 있습니다.
User-level threads처럼 작동하면서 Hardware Parallelism과 Blocking calls에 대처할 수 있으며, Context-Switch을 많이 하지 않습니다.
이것의 장애는, LWP가 Blocking이 되면 이 LWP가 가진 몇개의 Thread도 동시에 Blocking이 됩니다. 또한 LWP의 Context-Switch 비용은 Kernel-level threas보다 결코 싸지 않습니다. 또한 다중 CPU에서 효율적일려면 각 Thread는 각각 다른 LWP에 할당되어 있어야 합니다. 각 Thread의 LWP 할당과 LWP의 CPU 할당은 별개로서 이루어지기 때문에, 각 Thread가 서로다른 CPU에 할당될려면 이렇게 작동하겠끔 하는 매커니즘이 따로 존재하여야합니다.
이러한 이유로 인해 LWP에 의한 multiplexed threads는 궁극의 해결책은 못됩니다. 이상적으로, Kernel-level threads의 결정적인 단점인 Thread Context-Switch를 user-level threds만큼 빠르게만 한다면 그것으로서 모든 장애는 해결됩니다. 물론 이 방법은 있지만 여전히 문제점을 가지고 있습니다. 아래 방법입니다.
이 방법은 User-level threads들을 위한 특별한 지원을 kernel이 해주는겁니다. 그 부분은 Scheduler Activation이라 합니다. User-level threads 라이브러리는 커널에게 프로세스를 요구할때와 양도할때를 알려줍니다. 그러면 커널의 Scheduler Activation은 이것을 커널에 의한 프로세스 주소 공간으로 할당된 Virtual Processor로 표현합니다. 여기서 스케줄링과 Blocking 감지가 이루어지며, Granted processor,Preemptive thread,Blocked,Unblocked등등의 Event를 User-level의 런타임 시스템에게 알려줍니다.
개념적으로 이 방법이 가장 확실합니다만 이것은 단 한가지, 그러나 치명적일 수도 있는, 약점이 있습니다.
커널과 라이브러리 코드가 효율적인 교신을 위해 같은 주소 공간을 공유하기 때문에 예외적으로 높은 신뢰를 가지고 있어야 하며 bug-free이어야합니다. 이 방법은 개념적으로 비정상적인 작동(의도적인 비정상적 작동 포함)과 버그에 대해서 강건함(robust)을 가지지 못합니다.
SunOS는 multiplexed threads를 지원합니다. 그외(WindowsNT,MACH,OS/2)는 Kernel-level threads를 지원합니다. 이 책에서는 MACH가 Kernel-level threads를 지원한다고 되어 있지만 어떤 Web site에 가니 MACH도 LWP도 지원하는걸로 되어 있군요. 이것이 multiplexed threads를 지원한다라는건지 아님 User-level threads의 구현상의 한방법인지는 모르겠습니다. 어쩌면 둘은 말만 다를뿐 별로 차이가 없는 것일지도 모르겠고.
소스도 있으니 훝어 보는 것도 좋겠습니다. _________________ 9th Paladin위로
방준영 user
가입: 2003년 1월 22일 올린 글: 26
올려짐: 2003년1월23일 23:10 주제:
인용:Thread-Package Architectures는 크게 4가지가 있습니다. User-level threads, Kernel-level threads, multiplexed threads, kernel-supported user-level threads 분류가 약간 잘못 되었습니다. 쓰레드 모델은 크게
user-level threads (1-on-N)
kernel supported threads (1-on-1)
multi-level (userland/kernel hybrid) threads (M-on-N) 3가지가 있고, 스케줄러 액티베이션은 마지막 M:N 모델의 일종입니다. 순수
음..좋습니다. 이제 제가 님의 분류가 일리가 있는건지 한번 분석해보고 싶군요.할 말은 이미 충분히 많지만, 제가 님의 비판을 하기에 앞서, 님의 분류에서 개념이 제대로 설명이 안된걸 추측할 수가 없습니다. 1 on N과 1 on 1, M on N의 정확한 개념 또는 정의를 알려주세요. 가장 중요한걸 말 안하고 이러이러한게 있다고만하니 비판조차 하기가 힘듭니다.그리고 제 글에 대해서 분류가 틀렸다고 하니, 제가 쓴 글의 내용이나 알고 이런 소릴 하는건지 의문도 들고, 그러나, 머 어쨌거나, 용기가 대단하게 느껴진다기 보다 참으로 무모하다라는 생각이듭니다. 하룻강아지가 범 무서운줄 모르는 것같은 그런 거 말이죠.참고로 제가 쓴 글은 제가 습득한 지식을 기반으로 작성된게 아니라 MultiThreaded Programming – Thuan Q.Pham,Pankaj K.Garg의 7장 Thread-Package Architectures를 요약한겁니다. 맨끝부분 MACH와 Linux에서 사용 가능한 사용자-레벨에서의 Thread Package만 제가 조사해서 추가했을뿐입니다. 못믿겠으면 윈서 보고 대조해보세요.아무튼 1 on N과 1 on 1, M on N의 개념을 정확히 밝혀 주시기 바랍니다.
인용:할 말은 이미 충분히 많지만, 제가 님의 비판을 하기에 앞서, 님의 분류에서 개념이 제대로 설명이 안된걸 추측할 수가 없습니다. 1 on N과 1 on 1, M on N의 정확한 개념 또는 정의를 알려주세요. 가장 중요한걸 말 안하고 이러이러한게 있다고만하니 비판조차 하기가 힘듭니다. 글쎄요, 쓰레드에 관해 잘알고 계신 것처럼 말씀하시는 분이 1-on-N이나
M-on-N이 무엇인지 모른다고 하시니…이해가 안되지만, 아무튼,커널쪽에서 보면 하나의 쓰레드고 사용자쪽에서 보면 여러 개의 쓰레드인
모델을 1-on-N(1대N) 모델이라고 합니다. 사용자레벨 쓰레드를 이렇게
표현하죠. 두번째로, 커널쪽과 사용자쪽의 쓰레드가 1대1로 대응하는 모델을
1-on-1 이라고 합니다. 그리고 마지막으로 커널 쓰레드의 개수와 사용자
쓰레드의 개수가 1대1 대응관계를 이루지 않는 모델을 M-on-N 모델이라고
합니다. LWP나 스케줄러 액티베이션이 모두 M대N 모델입니다.인용: 그리고 제 글에 대해서 분류가 틀렸다고 하니, 제가 쓴 글의 내용이나 알고 이런 소릴 하는건지 의문도 들고, 그러나, 머 어쨌거나, 용기가 대단하게 느껴진다기 보다 참으로 무모하다라는 생각이듭니다. 하룻강아지가 범 무서운줄 모르는 것같은 그런 거 말이죠. 답변 내용중에 잘못된 점이 있으면 누구나 지적을 할 수 있는 것 아닙니까?
저는 단지 “분류가 약간 잘못되었다”고 말씀드렸을 뿐인데, 과잉반응을
하시는군요. 참고로 전 리눅스의 clone(2) 시스템 호출(LinuxThreads의 핵심이죠)을
NetBSD로 이식하는 작업에 참여했고, Wine 프로젝트를 위해 NetBSD
쓰레드 지원 작업을 하기도 했습니다. 물론 그둘은 모두 NetBSD와
Wine에 공식적으로 포함되어 있으니 제가 무엇을 했는지는 직접 코드를
보고 확인하셔도 좋습니다. 저보고 “하룻강아지 범 무서운 줄 모른다”는
Paladin님은 쓰레드로 무엇을 해보셨습니까?인용: 참고로 제가 쓴 글은 제가 습득한 지식을 기반으로 작성된게 아니라 MultiThreaded Programming – Thuan Q.Pham,Pankaj K.Garg의 7장 Thread-Package Architectures를 요약한겁니다. 맨끝부분 MACH와 Linux에서 사용 가능한 사용자-레벨에서의 Thread Package만 제가 조사해서 추가했을뿐입니다. 못믿겠으면 윈서 보고 대조해보세요. 못믿는 게 아니라 Paladin님이 책을 제대로 이해하지 못한 걸 지적한 것
여전하군요.개념/정의 질문을 한 이유는, 제가 님의 엉터리 논리의 저변까지 꿰뚫어 볼 수는 없는지라 재확인겸해서 한 질문인데, ‘그것도 모르냐’는 식으로 버릇없게 한술 더 뜨는군요. 게다가 여전히 개념과 일관성없는 단어 사용등 엉망이고. 논리적인 면에서도, 커널쪽에서 보면 몇개 사용자쪽에서 보면 몇개라는 식의 분류를, 그럴듯 하지도 않음에도 불구하고, 계속 M:N Model로 만들어서 몰고가고 있고.사용자-레벨에서의 쓰레드는 커널과는 완전히 무관하고, 커널이 보는건 이 쓰레드들을 담고 있는 하나의 프로세스뿐입니다. 그래서 님의 논리를 억지로 갖다 붙힌다하더라도, 커널이 보는 사용자-레벨의 쓰레드는 1개가 아니라 0개입니다.커널-레벨 쓰레드는 커널-레벨에서 돌아가는 쓰레드를 말하는거지만, 님의 논리대로 사용자 레벨에서 봐도(“사용자레벨에서 본다”라는 이 말자체가 문제이기 하지만) 쓰레드 1개가 돌고 있다고 봐도 무관한지라 1 on 1이라고 우기면 못 봐줄건 없습니다.LWP를 이용한 Multiplexing은 님의 논리와는 전혀 다르지만 M:N으로 넣어줄 수는 있습니다. 그러나 커널에서 보면 M개, 사용자 레벨에서 보면 N개가 아니라, LWP M개, Thread N개가 실재로 동시에 존재하는 겁니다.그리고 안타깝게도 스케줄러 액티베이션은 M:N이 아니군요. 이것은 사용자-레벨의 스레드를 위해 커널에서 지원(가상 프로세스, 이전 글 참조)을 해주는 것이지 어떤 M:N 관계가 있지는 않습니다.””단지 “분류가 약간 잘못되었다”고 말씀드렸을””제가 쓴 글은 책에 있는거고 제가 그 책의 분류와 내용에 아주 잘 이해하고 공감을 하는지라 머가 잘못되었다고 해서 흥분할 일은 없습니다. 다만 님이 말도 안되는 모델을 내세우며 “이게 맞아”라고 하니 뭔가 좀 정신이 들겠끔 해드리고 싶더군요. 님이 먼저 쓴 글은 그냥 무시(비하한다는 뉘앙스는 없고 ‘ignore’임)하였으나 (답장 안달았음) 님이 제 글에 답장을 다니 그냥 무시하고 지나갈 수가 없었습니다. 잘못된 지식이 한참 배우는자들에게 전달되면 참으로 피곤한 세상이 되는지라 미연에 막을 필요가 있었습니다.””참고로 전 리눅스의 clone(2) 시스템 호출(LinuxThreads의 핵심이죠)을
NetBSD로 이식하는 작업에 참여했고, Wine 프로젝트를 위해 NetBSD
쓰레드 지원 작업을 하기도 했습니다. 물론 그둘은 모두 NetBSD와
Wine에 공식적으로 포함되어 있으니 제가 무엇을 했는지는 직접 코드를
보고 확인하셔도 좋습니다””한 일(Porting,..)이 그다지 대단해 보이지도 않는데다, 전 님을 신뢰하지 않습니다. NetBSD에 대해 뭔가를 강조하지 말았으면 합니다. 솔직히 님을 보면 NetBSD까지 신뢰가 가지 않습니다.”못믿는 게 아니라 Paladin님이 책을 제대로 이해하지 못한 걸 지적한 것
뿐입니다. 책에서 스케줄러 액티베이션에 별도의 절을 할애해서 설명하고
있는 이유는 멀티레벨 쓰레드의 문제점을 해결하는 데 있어 현재까지 알려진
가장 훌륭한 해결책이기 때문에 그렇습니다.”말도 안되는건 끝까지 이어져 있군요. 지적이라니! 이해하지 못한걸 지적한다라니 어이가 없음.따끔한 충고 한마디하죠.계속 말안되는 말만해대면 무식함이 만천하에 드러나니 NetBSD를 위해서라도 자중하세요. 아님 진짜 제대로 설득을 보겠다고 하면, 해당 논리(M on N Model)에 대한 구체적인 논문 또는 자료를 하나라도 증거로서 제시해주든가. _________________ 9th Paladin
실력은 고사하고 기본적 예의부터 상당히 없으신 것 같군요. 첨보는 사람한테 하룻강아지 범무서운 줄 모른다고 무례한 말씀을 하실 때부터 알아봤어야 하는 건데, 좋습니다. 저도 님같은 분께는 별로 예의를 차리지 않겠습니다.인용:사용자-레벨에서의 쓰레드는 커널과는 완전히 무관하고, 커널이 보는건 이 쓰레드들을 담고 있는 하나의 프로세스뿐입니다. 그래서 님의 논리를 억지로 갖다 붙힌다하더라도, 커널이 보는 사용자-레벨의 쓰레드는 1개가 아니라 0개입니다. 혹시 “single threaded”란 표현은 들어보셨습니까? 뭐, 들어본 적이 없으니까쓰레드가 0개라는 반론을 하시겠지만요.1-on-1이니 M-on-N이니 하는 표현은 제가 만든 것도 아니고 쓰레드를 제대로 공부해 본 사람이라면 당연히 알고 있는 용어입니다. 또는 적어도 쓰레드 프로젝트 웹사이트에 한번이라도 방문해 본 적이 있다면 그 개념을 확인하기 위해 저한테 질문같은 건 하지 않겠지요? NGPT니 NPTL이니 하는 게 무슨 얘긴지도 물론 모르시겠고요.인용: 제가 쓴 글은 책에 있는거고 제가 그 책의 분류와 내용에 아주 잘 이해하고 공감을 하는지라 머가 잘못되었다고 해서 흥분할 일은 없습니다. 다만 님이 말도 안되는 모델을 내세우며 “이게 맞아”라고 하니 뭔가 좀 정신이 들겠끔 해드리고 싶더군요. 님이 먼저 쓴 글은 그냥 무시(비하한다는 뉘앙스는 없고 ‘ignore’임)하였으나 (답장 안달았음) 님이 제 글에 답장을 다니 그냥 무시하고 지나갈 수가 없었습니다. 잘못된 지식이 한참 배우는자들에게 전달되면 참으로 피곤한 세상이 되는지라 미연에 막을 필요가 있었습니다. 어줍잖게 책 한두번 읽어보고 쓰레드에 관해 마치 전문가인양 행세하지 마시기 바랍니다.이전 글을 다시 읽어보니 SunOS가 multiplexed thread라는 철지난 얘기를 어디서 주워들어 써놓으셨군요. 솔라리스 2.6부터는 기존 LWP에다 스케줄러 액티베이션을 구현해서 쓰고 있는데, 이건 multiplexed thread입니까, kernel supported user-level thread입니까? 헷갈리시죠? 덧붙여 스케줄러 액티베이션이 어떤 원리로 어떻게 동작하는지 설명을 부탁드려도 될까요?인용: 한 일(Porting,..)이 그다지 대단해 보이지도 않는데다, 전 님을 신뢰하지 않습니다. NetBSD에 대해 뭔가를 강조하지 말았으면 합니다. 솔직히 님을 보면 NetBSD까지 신뢰가 가지 않습니다. 초등생 수준의 논리적 사고력을 가진 분 같군요. “저는 님처럼 모르는 걸 아는 체 하는 사람을 보면 사람자체까지 신뢰가 가지 않습니다.” 제가 그다지 대단하지 않은 일을 하는 동안 님은 쓰레드로 무슨 일을 해봤습니까? 한번도 프로그램을 짜본 적도 없으면서 이러쿵 저러쿵 떠드는 거 아닌지 의심스럽습니다.인용: 계속 말안되는 말만해대면 무식함이 만천하에 드러나니 NetBSD를 위해서라도 자중하세요. 아님 진짜 제대로 설득을 보겠다고 하면, 해당 논리(M on N Model)에 대한 구체적인 논문 또는 자료를 하나라도 증거로서 제시해주든가. 하늘에 해가 떠있는 걸 증명하란 소리로 들리는군요. 님이 단 한번이라도 쓰레드 분야의 논문을 읽어본 적이 있다면 그런 걸 증거로 제시하란 요구는 못하실 텐데요. 혹시 Usenix라고 들어보셨습니까? Siteseer는요? 못들어 보셨으면 Google이라고 괜찮은 검색 엔진이 있는데 거기서 한번 검색해 보시기 바랍니다.아니면 아무 쓰레드 프로젝트 사이트에 “어떤 멍청이가 M-on-N 모델이란 쓰레드가 있다고 우기는 데 나는 믿을 수가 없다. 그게 도대체 무슨 소리냐”고 질문을 던져보시는 것도 괜찮을 듯 합니다.
저녁을 먹느라 아랫 부분에 대한 지적을 빠뜨렸습니다.Paladin 씀:커널-레벨 쓰레드는 커널-레벨에서 돌아가는 쓰레드를 말하는거지만, 님의 논리대로 사용자 레벨에서 봐도(“사용자레벨에서 본다”라는 이 말자체가 문제이기 하지만) 쓰레드 1개가 돌고 있다고 봐도 무관한지라 1 on 1이라고 우기면 못 봐줄건 없습니다.LWP를 이용한 Multiplexing은 님의 논리와는 전혀 다르지만 M:N으로 넣어줄 수는 있습니다. 그러나 커널에서 보면 M개, 사용자 레벨에서 보면 N개가 아니라, LWP M개, Thread N개가 실재로 동시에 존재하는 겁니다.그리고 안타깝게도 스케줄러 액티베이션은 M:N이 아니군요. 이것은 사용자-레벨의 스레드를 위해 커널에서 지원(가상 프로세스, 이전 글 참조)을 해주는 것이지 어떤 M:N 관계가 있지는 않습니다.
대단히 말도 안되는 주장을 정색을 하고 말씀하시기에, 바라시던 논문에서 한 부분 인용해서 보여드리겠습니다:Williams, N., An Implementation of Scheduler Activations on the NetBSD Operating System, 2002 씀:Since there are advantages and disadvantages of both the N:1 and 1:1 thread implementation models, it is natural to attempt to combine them to achieve a balance of the costs and benefits of each. These hybrids are collectively known as “N:M” systems, since they map some number N of application threads onto a (usually smaller) number M of kernel entities. They are also known as “two-level” thread systems, since there are two parties, the kernel and the user parts of the thread system, involved in thread operations and scheduling. There are quite a variety of different implementations of N:M thread systems, with different performance characteristics. N:M thread systems are more complicated than either of the other models, and can be more difficult to develop, debug, and use effectively. Both AIX and Solaris use N:M thread systems by default.In a N:M thread system, a key question is how to manage the mapping of user threads to kernel entities. One possibility is to associate groups of threads with single kernel entities; this permits concurrency across groups but not within groups, reaching a balance between the concurrency of N:1 and 1:1 systems.The scheduler activations model put forward by Anderson et al. is a way of managing the N:M mapping while maintaining as much concurrency as a 1:1 thread system.
스케줄러 액티베이션을 직접 구현한 사람이 스케줄러 액티베이션이 N:M 모델이라는데, 교과서만 한두번 읽어보고 쓰레드를 잘 안다고 자부하는 사람은 그게 아니라고 합니다. 더 망신당하실까봐 1-on-1 모델에 대한 인용은 생략하도록 하겠습니다.혹시라도 논문에 kernel entities라고 되어 있지 kernel threads라고 되어 있지는 않지 않느냐는 생트집은 잡지 마시기 바랍니다. Solaris와 NetBSD에서는 kernel entity를 LWP라고 부르고, 리눅스, 윈도, FreeBSD에서는 thread라고 부르는 것 뿐입니다.
