'커널수준 쓰레드'에 해당되는 글 1건

일반적으로 많이 나와있는 내용이라 찾아보시면 자료들이 많을겁니다만..

간단하게 생각해보면, (저도 자세히는 모르지만 -_-)

user thread는 process내부에 여러개로 구성될 수 있고, 한 process내에서
같은 리소스를 가지고 다른 user thread와 통신할 수 있으니 당연히 context switching의 overhead가 없죠.

kernel thread는 user thread에서 LWP 자료구조를 통해 연결되는데,
보통 kernel scheduler에 의해 cpu를 할당받아 사용하지만, 직접 cpu를 할당 받아서 사용할 수도 있으니 당연히 효율(?)적일 수도 있겠죠.. 쿨럭.. :shock:

문맥교환은 컨텍스트 전환(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도 능가한다고 큼지막하게 써놨습니다.

중요한 것은 아닙니다만...

LWP는 경량 프로세스(lightweight process)의 준말로, 솔라리스에서(그리고
최근의 NetBSD에서) 내부적으로 쓰는 말입니다. 리눅스, 윈도, FreeBSD에선
그냥 thread라고 합니다.

--
http://www.kr.netbsd.org/~junyoung

참조 하세요. 이 글 쓰느라 시간 좀 들였습니다.

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만큼 빠르게만 한다면 그것으로서 모든 장애는 해결됩니다. 물론 이 방법은 있지만 여전히 문제점을 가지고 있습니다. 아래 방법입니다.

[Scheduler Activation(kernel-supported user-level threads)]

이 방법은 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의 구현상의 한방법인지는 모르겠습니다. 어쩌면 둘은 말만 다를뿐 별로 차이가 없는 것일지도 모르겠고.

Linux에서 작동되는 User-level threads는 아래와 같습니다.
Bare-Bones Threads,CLthreads,DCEthreads,FSU Pthreads,JKthread,LinuxThreads,LWP,NThreads (Numerical Threads),PCthreads,Provenzano Pthreads,QuickThreads,RexThreads.
http://www.sftw.umac.mo/resource/LDP/FAQ/Threads-FAQ/ThreadLibs.html에서 퍼왔습니다.
소스도 있으니 훝어 보는 것도 좋겠습니다.

분류가 약간 잘못 되었습니다. 쓰레드 모델은 크게

user-level threads (1-on-N)
kernel supported threads (1-on-1)
multi-level (userland/kernel hybrid) threads (M-on-N)

3가지가 있고, 스케줄러 액티베이션은 마지막 M:N 모델의 일종입니다. 순수
사용자수준 쓰레드의 대표적인 것으로 GNU Pth, FreeBSD libc_r이 있고,
1:1 커널 쓰레드는 리눅스의 glibc/LinuxThreads, 윈도의 고유 쓰레드
등이 있습니다. M:N 쓰레드는 솔라리스 예전 버전의 "순수" M:N 모델이
있고, 최근 솔라리스 7,8에서는 스케줄러 액티베이션을 사용합니다(버전
9부터는 다시 1:1 쓰레드가 기본 쓰레드로 사용됩니다). 그리고 NetBSD의
스케줄러 액티베이션과 FreeBSD의 커널 스케줄러 엔티티도 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이나
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님은 쓰레드로 무엇을 해보셨습니까?

못믿는 게 아니라 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)에 대한 구체적인 논문 또는 자료를 하나라도 증거로서 제시해주든가.

실력은 고사하고 기본적 예의부터 상당히 없으신 것 같군요. 첨보는 사람한테 하룻강아지 범무서운 줄 모른다고 무례한 말씀을 하실 때부터 알아봤어야 하는 건데, 좋습니다. 저도 님같은 분께는 별로 예의를 차리지 않겠습니다.

혹시 "single threaded"란 표현은 들어보셨습니까? 뭐, 들어본 적이 없으니까쓰레드가 0개라는 반론을 하시겠지만요.

1-on-1이니 M-on-N이니 하는 표현은 제가 만든 것도 아니고 쓰레드를 제대로 공부해 본 사람이라면 당연히 알고 있는 용어입니다. 또는 적어도 쓰레드 프로젝트 웹사이트에 한번이라도 방문해 본 적이 있다면 그 개념을 확인하기 위해 저한테 질문같은 건 하지 않겠지요? NGPT니 NPTL이니 하는 게 무슨 얘긴지도 물론 모르시겠고요.

어줍잖게 책 한두번 읽어보고 쓰레드에 관해 마치 전문가인양 행세하지 마시기 바랍니다.

이전 글을 다시 읽어보니 SunOS가 multiplexed thread라는 철지난 얘기를 어디서 주워들어 써놓으셨군요. 솔라리스 2.6부터는 기존 LWP에다 스케줄러 액티베이션을 구현해서 쓰고 있는데, 이건 multiplexed thread입니까, kernel supported user-level thread입니까? 헷갈리시죠? 덧붙여 스케줄러 액티베이션이 어떤 원리로 어떻게 동작하는지 설명을 부탁드려도 될까요?

초등생 수준의 논리적 사고력을 가진 분 같군요. "저는 님처럼 모르는 걸 아는 체 하는 사람을 보면 사람자체까지 신뢰가 가지 않습니다." :D

제가 그다지 대단하지 않은 일을 하는 동안 님은 쓰레드로 무슨 일을 해봤습니까? 한번도 프로그램을 짜본 적도 없으면서 이러쿵 저러쿵 떠드는 거 아닌지 의심스럽습니다.

하늘에 해가 떠있는 걸 증명하란 소리로 들리는군요. 님이 단 한번이라도 쓰레드 분야의 논문을 읽어본 적이 있다면 그런 걸 증거로 제시하란 요구는 못하실 텐데요. 혹시 Usenix라고 들어보셨습니까? Siteseer는요? 못들어 보셨으면 Google이라고 괜찮은 검색 엔진이 있는데 거기서 한번 검색해 보시기 바랍니다.

아니면 아무 쓰레드 프로젝트 사이트에 "어떤 멍청이가 M-on-N 모델이란 쓰레드가 있다고 우기는 데 나는 믿을 수가 없다. 그게 도대체 무슨 소리냐"고 질문을 던져보시는 것도 괜찮을 듯 합니다.

저녁을 먹느라 아랫 부분에 대한 지적을 빠뜨렸습니다.

대단히 말도 안되는 주장을 정색을 하고 말씀하시기에, 바라시던 논문에서 한 부분 인용해서 보여드리겠습니다:

스케줄러 액티베이션을 직접 구현한 사람이 스케줄러 액티베이션이 N:M 모델이라는데, 교과서만 한두번 읽어보고 쓰레드를 잘 안다고 자부하는 사람은 그게 아니라고 합니다. 더 망신당하실까봐 1-on-1 모델에 대한 인용은 생략하도록 하겠습니다.

혹시라도 논문에 kernel entities라고 되어 있지 kernel threads라고 되어 있지는 않지 않느냐는 생트집은 잡지 마시기 바랍니다. Solaris와 NetBSD에서는 kernel entity를 LWP라고 부르고, 리눅스, 윈도, FreeBSD에서는 thread라고 부르는 것 뿐입니다.

질문에 대한 답글은 아니지만,
바로 위의 글들이 눈살을 찌프리게 하기에 제3자의 입장에서 몇자적습니다.
토론이 아니라 논쟁이 된듯합니다. :(
제3자의 입장에서야 도움이 되는 글이 많으니 흥미로운 글들이지만,
두분이 서로 감정이 달아오른듯 싶군요. 후후....

다음글을 읽으시고 이성을 찾으시기 바랍니다.
http://arteeth.com/photo/semiology.htm

여전히 여전하군요.

"실력은 고사하고 기본적 예의부터 상당히 없으신 것 같군요. 첨보는 사람한테 하룻강아지 범무서운 줄 모른다고 무례한 말씀을 하실 때부터 알아봤어야 하는 건데, 좋습니다. 저도 님같은 분께는 별로 예의를 차리지 않겠습니다"

이전에는 예의를 차렸던가요? ㅎㅎㅎ (이제는 비웃음입니다)
엉터리 논리를 끝까지 밀어부치는 그 신념 높이 살만합니다만 그만큼 님의 한계는 다가오는 셈이겠죠.

싱글 쓰레드라...

이제와서 "프로세스가 단일 쓰레드이다"라는 주장같은거 하는거라면 뒷구멍으로 도망치지마라고 한방 날리겠습니다. 이런 뒷구멍을 미리 막지 못한 저의 불찰이겠지만. 프로세스와 쓰레드는 분명하게 다른겁니다. 이것도 이전 글에 미리 말하려고 했으나 설마 이렇게까지 나갈줄은 몰랐군요.

"1-on-1이니 M-on-N이니 하는 표현은 제가 만든 것도 아니고 쓰레드를 제대로 공부해 본 사람이라면 당연히 알고 있는 용어입니다. 또는 적어도 쓰레드 프로젝트 웹사이트에 한번이라도 방문해 본 적이 있다면 그 개념을 확인하기 위해 저한테 질문같은 건 하지 않겠지요? NGPT니 NPTL이니 하는 게 무슨 얘긴지도 물론 모르시겠고요."

솔직히 NGPL,NPTL같은 이따위 것들 모릅니다. NGPL,NPTL이 쓰레드 일반 이론을 대체할만큼 대단한건지는 제가 판단을 일단 유보하죠. 얼마나 대단한 것이길래 그것이 마치 모든 쓰레드의 일반 이론인양 주장하는건지는 좀 더 두고 보죠.

그러나 저는 님이 저런거 안다고 어디서 줏어 들어다고 까지 표현을 않겠습니다. 이 시점에서 님이 써둔 글을 다시금 한번 보세요.

"이전 글을 다시 읽어보니 SunOS가 multiplexed thread라는 철지난 얘기를 어디서 주워들어 써놓으셨군요. 솔라리스 2.6부터는 기존 LWP에다 스케줄러 액티베이션을 구현해서 쓰고 있는데, 이건 multiplexed thread입니까, kernel supported user-level thread입니까? 헷갈리시죠? 덧붙여 스케줄러 액티베이션이 어떤 원리로 어떻게 동작하는지 설명을 부탁드려도 될까요? "

철지난 얘기를 줏어 들어다라니 참으로 어이가 없군요. 제가 말한건 책의 내용을 요약했다고 분명히 말했습니다. 요약(summary)이 무슨 뜻인지 모르면, 국어 사전(요약) 또는 영어 사전(Summary) 보고 의미를 파악하기 바랍니다.

LWP에다 스케줄러 액티베이션을 썩어놓으면 먼가 라는 질문, 이런 허접한 질문 만드느라 애썼습니다. 답을 말해드리죠. kernel supported and multiplexed user-level thread입니다.

그리고 크게 4개로 나눈다고 하는 것은, 모든 패키지 아키텍쳐가 님의 M:N모델 분류처럼 어느 한곳에 속해야함을 강제하진 않습니다. 님의 논리라면 이런 질문할 법도 하기에 답변을 해드렸습니다. 참고로 원칙적으로 보면 Kernel-Level, User-Level Threads 두개고 나머지는 하이브리드 형태입니다.

"" 초등생 수준의 논리적 사고력을 가진 분 같군요. "저는 님처럼 모르는 걸 아는 체 하는 사람을 보면 사람자체까지 신뢰가 가지 않습니다." ""

ㅎㅎㅎ, 유치원생같은 수준 낮은 표현, 조금 수준 높은 제가 참죠.

"제가 그다지 대단하지 않은 일을 하는 동안 님은 쓰레드로 무슨 일을 해봤습니까? 한번도 프로그램을 짜본 적도 없으면서 이러쿵 저러쿵 떠드는 거 아닌지 의심스럽습니다."

이런 의심을 한다고한들 님에게 도움이 되는 것은 무엇인가요? 상대가 무너지면 그냥 자기 논리가 인정받는건가요? ㅎㅎㅎ, 그런 기대를 한다라는 것 자체가 자신의 한계를 간접 노출하는 셈입니다. 그리고 생각을 해보세요. 머리가 있다면. 제가 경험이나 지식이 없다면, Pham과 Garg의 책 내용을 요약하는게 가능했을까요? 전 리눅스를 비롯한 Open Source가 대중화되기전부터 윈도우에서 Socket + Multi-Thread 프로그래밍을 한 사람입니다. 기회만 된다면(경제적 문제만 해결되면) 그리고 원한다면 쓰레드 패키지를 Porting같은 짓꺼리 안하고 아예 이론대로 구현해보일 수도 있습니다.

"하늘에 해가 떠있는 걸 증명하란 소리로 들리는군요. 님이 단 한번이라도 쓰레드 분야의 논문을 읽어본 적이 있다면 그런 걸 증거로 제시하란 요구는 못하실 텐데요. 혹시 Usenix라고 들어보셨습니까? Siteseer는요? 못들어 보셨으면 Google이라고 괜찮은 검색 엔진이 있는데 거기서 한번 검색해 보시기 바랍니다."

님의 어슬픈 M:N model이 과연 님이 말하는 논리대로 존재하고 있는건지 의심스러워서 자료를 요구한겁니다. 이 요구가 "하늘의 해가 떠 있는걸 증명하라"는 것처럼 황당한 요구였나요? 이런 단순한 요구가 그렇게 어려운 요구였다니, 결과적으로 님의 그 한계가 또 간접 노출되는 셈이죠.
그리고 어디서 뭘보고 저러는건지를 제가 찾아서 파악해야하나요? 귀찮아서 그렇겐 못하겠소. 제가 자료를 찾지 못해서 그런 요구를 했다라니 계속 이런 유치한 발상을 하면 할수록 님의 신뢰도는 점점 추락하는셈입니다.

"저녁을 먹느라 아랫 부분에 대한 지적을 빠뜨렸습니다."

'밥 빨리 쳐먹어'라고 말하고 싶은 욕구가 가득합니다만, 이런 말은 쓰지 않은걸로 하자면 또 하룻강아지에 대한 속담처럼 오바을 할테죠. 그러지 말기 바랍니다. 이 표현에 대해서만 이미 글은 썻지만 사과도 첨부합니다. 사과를 첨부한다라는 말은 "병주고 약주냐 이 자식아"라고 말하면 기꺼이 받아 들이겠다라는 말입니다.

"대단히 말도 안되는 주장을 정색을 하고 말씀하시기에, 바라시던 논문에서 한 부분 인용해서 보여드리겠습니다"

이젠 아예 책의 내용 자체를 부정하기 시작하는군요. Pham과 Garg의 책을 신뢰하지 않는 모양인데. 그렇다면 탄넨바움의 책은 어떤가요?

"스케줄러 액티베이션을 직접 구현한 사람이 스케줄러 액티베이션이 N:M 모델이라는데, 교과서만 한두번 읽어보고 쓰레드를 잘 안다고 자부하는 사람은 그게 아니라고 합니다. 더 망신당하실까봐 1-on-1 모델에 대한 인용은 생략하도록 하겠습니다. "

이제서야 그 정체가 드러났군요.

"Williams, N., An Implementation of Scheduler Activations on the NetBSD Operating System"이라.

스케줄러 액티베이션은 1991년 앤더슨에 의해 창조되어져습니다. 논문을 알려드리죠.

"Scheduler Activations : Effective Kernel Support for User-Level Management of Parallelism" - Anderson,Bershad,Lazowska,Levy, 1991, proceedings of the 13th Symposium on Operating Principles, pp 95-109

저도 이 논문을 직접 읽지는 않았습니다. 허나 Pham과 Garg의 책에 있는 스케줄러 액티베이션은 이 논문을 보고 참조/요약한겁니다. 그리고 윌리엄도 원자자의 내용을 확뒤집었다면 굳이 스케줄러 액티베이션이라고 말할 필요가 없었겠죠.

그리고 인용한 것도 짚고 넘어가야겠죠.

""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. ""

""혹시라도 논문에 kernel entities라고 되어 있지 kernel threads라고 되어 있지는 않지 않느냐는생트집은 잡지 마시기 바랍니다. Solaris와 NetBSD에서는 kernel entity를 LWP라고 부르고, 리눅스, 윈도, FreeBSD에서는 thread라고 부르는 것 뿐입니다"""

황당하군. 쭉읽어 보고나니, 문제가 바로 드러나는데, 그런데!! 마지막 단락에서, 명백히 드러난 자기 잘못을 인정하기는 커녕 '생트집 하지 말라'니. 궁지에 몰린 쥐처럼 보이는군요. 적반하장이란 고사성어와 방귀 뀐 놈이 도려 성낸다라는 속담도 떠오르고.

kernel entity에 LWP도 있다라고 하면 인정해주겠지만, kernel entity를 LWP라고 부른다니 이걸 말이라고 하는건지. 한술 더 떠서 다른 OS에서는 thread라고 부른다라니!!

ㅎㅎㅎ(허탈)

제3자를 위해서 좀 더 붙이죠.

위 글에 분명하게 드러난건 님이 이전에 말한, 바로 이때 써먹을려고 뒷구멍을 막아둔 것임, 커널에서 보면 M개 쓰레드, 사용자 레벨에서 보면 N개 쓰레드라는 것은 분명한 허구임이 밝혀졌습니다. 이런말 한적 없다고 생각되면 님이 쓴 글 다시 읽어 보기 바람.

N:1 and 1:1 thread implementation models의 정의는 없지만, N:M systems이라 불리는건 N개의 어플이케이션 쓰레드가 N개의 커널 앤티티로 매핑(Map)되에 이것들의 짬뽕(Hybrid)이다라고 하므로 N:1 and 1:1이 무엇인지는 유추됩니다.

User-Level이 N:1인 경우는 N개의 쓰레드가 동시에 접근할 수 있는 커널의 앤티티가 결국 하나라는것이지 커널이 보는 쓰레드가 하나라는 것이 아닙니다. 커널이 보는건 단 하나의 프로세스이며 단일 프로세스는 커널 자원(또는 앤티티)에 한번에 하나씩 차례로 접근(또는 호출)을 하죠. Kernel-Level이 1:1인 경우는 커널-레벨의 쓰레드는 각각 독립적으로 커널 앤티티에 접근하기에 쓰레드:커널앤티티가 1:1인 겁니다.

다시 정리하자면 커널 앤티티란 커널이 보는 쓰레드가 아니라 커널이 제공하는 함수나 공유 변수 또는 기타 자원을 의미하죠. 사실 이렇게 말하기도 머하고, 앤티티는 그냥 엔티티입니다.

자 오늘은 이쯤해두죠. 내일은 여전할런지 아님 좀 성숙해질런지 두고보겠습니다.

위의 두분의 토론을 보고 많은 걸 배우네요..

두분께 감사드립니다.

본론은

팔라딘님 글이 너무 '직설적'이네요

처음보는 분한테 '하룻강아지 범 무서운 줄 모르는...'이라는 말은

너무 과격합니다.

조금 더 예의를 갖춰서 토론을 시작한다면 팔라딘님의

지식이 더욱 빛나겠죠? :D

이글을 읽고 계실 많은 분들께 험악하게 싸우는 모습을 보여드려 죄송하다는 말씀을 드리고 싶습니다. 그렇지만 이렇게 싸워가는 가운데 상대방을 이기기 위해 공부도 하고, 나름대로의 논리도 개발하다보면, 그리고 여러분은 중간 입장에서 누구 말이 옳고 그른지 판단하시다 보면, 결과적으로 모두에게 그리 나쁠 것은 없다는 생각이 들기도 합니다. 그러니 "이 사람들 뭐 이렇게 쓸데없이 핏대 올려가며 싸우냐"고 생각하시기보다, 그냥 편한 연속극이나 코메디( :!: ) 프로 시청하시듯이 감상( :?: )해 주시면 감사하겠습니다.

쯧쯧, 그 한방은 님에게나 날리시죠. 책 한권 달랑 읽어놓고 아는 척 하려니 그런 말이 있는 것조차도 모르셨군요. 제가 Google이라고 괜찮은 검색 엔진있다고 말씀 안드렸던가요? 거기서 single thread multi thread라고 검색하면 몇개나 나오는지 개수부터 세어보시죠. 남들은 그런 표현을 쓰레드 개념이 나올 때부터 줄곧 써왔는데 자기가 배운 책에 안나오면 전부 엉터리라니...쩝, 할말을 잃게 만듭니다.

허! 딱 걸렸습니다. 님이 "쓰맹"이란 사실을요. 리눅스나 오픈 소스 시스템 프로그래밍 쪽에선 NGPT와 NPTL이 요즘 대단한 관심사인데 그걸 모른다구요? 지금 우리가 이렇게 싸우고 있는 걸 구경하고 계신 분들도 모두 잘 알고 계시는 것인데 그걸 모른다고 말씀하시나요? 차라리 리눅스란 운영체제를 들어본 적이 없다고 말씀하시지 그래요? 모르면 "이따위것들"로 치부해 버릴 수 있는 용기에 감탄이 절로 나옵니다.

옛날 책을 보고 철지난 얘기를 하시길래 지적한 겁니다. 혹시나 해서 아마존에서 찾아봤더니 그책은 "Multithreaded Programming with Windows NT" (1995년 12월 출간)이나 "Multithreaded Programming with Win32" (1998년 11월) 둘중 하나겠더군요. 그런데 정말 황당하기 짝이 없는 건, 스케줄러 액티베이션은 7장에서 142페이지와 143페이지에 걸쳐 달랑 한 페이지로 요약이 되어 있다는 점이었습니다. 결국 한페이지 읽어 놓고 스케줄러 액티베이션이 어쩌고 저쩌고하는 전문가 행세를 하셨던 것이었습니다. 전문가가 된다는 게 이렇게 간단하고 쉬웠던 것인가요? 뜨아~ :oops:

하하하, 지구상의 어느 책에도 없는 괴상망칙한 표현을 멋대로 만들어내시는군요. 말씀하신대로라면 쓰레드 모델이 4개가 아니라 다섯 개 아닙니까? 그러면 FreeBSD의 커널 스케줄러 엔티티는 kernel supported and multiplexed user-level thread with system-level contention added 모델이라고 하면 맞나요? 제가 잘 몰라서 그런 것이니 설명 부탁드립니다.

허, 제가 3개라고 그랬더니 아니라고 해놓고 나머지는 하이브리드 형태라니 무슨 말씀이세요?

참아주셔서 감사합니다. :D 그런데 위에 보면 한방 날리고 싶은, 밑에 보면 쳐먹어, 뭐 이런 표현을 적어 놓으셨던데 그런 건 수준높은 분들이 사용하는 표현인가보죠? 죄송합니다. 저는 수준이 낮아서 그런 표현은 도저히 머리에 떠오르질 않았습니다. 게다가 처음보는 사람한테 무모하다, 하룻강아지다, 알고나 이런 소릴 등등의 표현을 사용하시는 걸 보니 담력과 문학적 감각 또한 탁월하십니다.

저를 신뢰하지 않는다고 먼저 말씀하신 쪽은 누구였는지 모르겠군요(저는 NetBSD와 Wine 두 개의 예를 들었는데 Wine은 쏙 빼고 NetBSD만 싸잡아 매도한 이유가 뭔지도 궁금해지네요). 그렇게 신뢰하지 않아서 님에게 도움된 것은 무엇이었나요? 경험이나 지식이 그렇게 풍부한 분이 1:1, M:N이 억지라고 하고, NGPT, NPTL, single threaded를 들어본 적이 없다고 지금 말씀하시나요? 그리고 신빙성에 지극히 의심이 가는 주장은 삼가시기 바랍니다. 리눅스를 비롯한 오픈 소스가 대중화되기 전이면 1993,4년일 텐데, 윈도 3.1에서 멀티 쓰레드 프로그래밍을 해보셨나요? 아니면, 제 기억에 1995,6년에조차도 멀티 쓰레드 프로그램이 윈도상에 그렇게 많지 않았던 걸로 기억하는데, 그때 벌써 멀티 쓰레드 프로그래밍을 하신 분이 국내에 계셨다니 놀라움을 금할 수 없군요. :o 아, 그리고 무슨 "기회가 된다면" 같은 하나마나 한 말씀도 안하셔도 됩니다. 저도 기회만 된다면, 경제적 문제만 해결된다면, 윈도보다, 리눅스보다 1억의 1조배는 훌륭한 OS를 만들려고 계획중입니다. 다른 모든 분들도 시간만 나면, 경제적 문제만 해결되면 제가 만들 프로그램보다 곱의 제곱으로 엄청나게 훌륭한 프로그램들을 만들려고 구상하고 계실 겁니다.

M:N 모델이 제 논리대로 존재하고 있냐고요? 제가 인용한 논문 안읽으셨습니까? 하늘의 해는 하느님의 논리대로 존재하고 있습니까?

허, 수준이 좀 높은 분들은 다른 사람 밥먹을 때 "쳐먹어"라고 말하고 싶은 욕구를 느끼기도 하나 봅니다. 뭐 좋습니다. 수준이 높아서 그런건데 제가 뭐라 할 수 있나요.

책을 엉뚱하게 요약해서 오해하셔 놓고는 제가 책 내용 자체를 부정한다니요.

꽈당~. 마이크로소프트웨어 2002년 6월호에서 제가 쓴 글의 참고문헌에 무슨 논문이 나열되어 있는지 확인해 보시죠. 물론 마이크로소프트웨어란 잡지가 있는지조차도 모르고 계실 가능성이 높다고 예상합니다만.

하하하, 제가 그 논문에 있는 내용 물어볼까 겁이 나셨나봐요. 미리 안읽었다고 선수를 치시는 걸 보면요(퀴즈: 업콜이 뭡니까?). 그런데 스케줄러 액티베이션에 관해 논문 한편도 제대로 안읽고 이렇다 저렇다 논평을 하십니까. "내용을 확 뒤집었다면"이란 뜬금없는 가정은 어떻게 설정하셨는지도 설명해 주시면 감사하겠습니다.

자기 잘못은 절대 인정안하시는군요. 분명히 스케줄러 액티베이션은 M:N 모델이 아니라고 주장하시지 않았습니까? "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."의 어느 부분이 해석하기에 곤란합니까?

같은 논문에서 한 부분 더 인용해 드리죠:

각각의 커널 엔티티는 실행 컨텍스트를 나타내고, 실행 컨텍스트는 커널 내에서 struct lwp로 표현됩니다. 이제 무슨 뜻인지 아시겠습니까. 커널 엔티티가 무슨 대단하고 설명하기 힘든 존재로 오해하고 계셔서 드리는 말씀입니다.

아예 하지도 않은 말을 조작까지 하시는군요. 제가 쓴 그대로 다시 인용할까요: "커널쪽에서 보면 하나의 쓰레드고 사용자쪽에서 보면 여러 개의 쓰레드인 모델을 1-on-N(1대N) 모델이라고 합니다. 사용자레벨 쓰레드를 이렇게 표현하죠. 두번째로, 커널쪽과 사용자쪽의 쓰레드가 1대1로 대응하는 모델을
1-on-1 이라고 합니다. 그리고 마지막으로 커널 쓰레드의 개수와 사용자 쓰레드의 개수가 1대1 대응관계를 이루지 않는 모델을 M-on-N 모델이라고 합니다. LWP나 스케줄러 액티베이션이 모두 M대N 모델입니다." 제 글의 어느 부분에 "커널에서 보면 M개 쓰레드, 사용자 레벨에서 보면 N개 쓰레드"라고 되어 있나요? 1-on-N 모델의 설명과 혼동이 되셨다면 더 명확하게 정정하겠습니다. "커널 쪽의 하나의 쓰레드와 사용자쪽의 여러 개의 쓰레드가 대응하는 모델을 1-on-N라 한다"

하늘의 해를 유추를 통해 발견하다니! :shock:

1:1의 의미가 커널-레벨 쓰레드와 커널 엔티티가 1대1로 접근하기 때문이라니, 기절초풍할 이론입니다! 아까전엔

이라고 1:1 모델을 부정하시더니 그새 1:1의 의미를 유추를 통해 깨달으셨나봐요? 제가 학교 다닐 때 찍기만 하면 틀리는 친구가 있었는데, 님은 하는 유추마다 어찌 답을 비켜가십니까? :D

수준높으신 분이 내일은 또 어떤 수준 높은 문구로 저를 공격하실지 기대가 됩니다.

이 이야기가 더이상 늘어나면 서로 감정이 상하는 것은 물론이고, 제3자들도 내용을 파악하기가 더욱 어려워질 테니 앞으로 Paladin님과 방준영님 모두 한 개씩의 글을 더 올리실 수 있는 기회를 드리고 이 주제에 대해 누구도 더이상 답글을 달 수 없도록 설정을 바꾸도록 하겠습니다. :?

보통 이 정도 단계에서 계속해서 댓글을 달게 되면 실질적인 정보교환은 갈수록 어려워지고 처음의 논의와는 완전히 다른 방향으로 가게 되는 것을 많이 보아 왔지요.... :roll:

두분께서 올려주신 지식은 분명 많은 사람들에게 좋은 정보가 될 수 있을 것입니다. 두분께서는 서로 흥분을 가라앉히시고 부디 좋은 모습으로 이번 주제를 마무리하실 수 있기를 바랍니다. :mrgreen:

감사합니다....

현재 코 길이가 피노키오를 능가하는지라 코를 납작하게 하는 방법으로는 도저히 안되겠군요. 톱으로 잘라내도 다시 자라날테니 이젠 그냥 콧구멍 파는 모습이나 지켜보죠. 머 드러날건 다 드러났으니 손으로 코를 아둥바둥 가린다고 한들 그 코가 감춰지는 것도 아닐테니. 그런데 그런 우스꽝스러운 모습을 즐거워하는 독자들도 있을테니 최대한 가려보기 바랍니다.

책은 MultiThread Programming with win32-Prentice Hall,1999입니다. 한권의 출판된 책은 인터넷상에서 떠도는 막연한 자료와는 그 신뢰성의 정도가 다르죠. 머 사실 신뢰성도 책나름이겠지만 이 책을 읽어 보면 알겠지만 운영체제 책에서 언급하지 않는 구체적인 부분이 많이 들어 있죠.

그런데 이걸 철지난 책이라 하니 기가 차는군요. 이 말은 내용도 구식이라는 말같은데 정말 어이없음.

그리고 single threaded (끝의 -ed가 중요, 놓칠수 없는 부분임)라고 해놓고선, 혀차면서 발뺌하는 것 좀 보게나! 정말 기가 차는군. 아예 소설가로 전업하는게 나을듯하군요.

그리고 난 Google보단 yahoo.com 쓴다네. yahoo.com도 나올만한 자료 다 나오니 참 쓸데없는 의심같은건 하지 말기 바람. 유치원생도 아니고 이게 뭐야 대체. 독자를 위해 이젠 수준 좀 높입시다.

NGPT,NPTL 오래 써먹는군. "커널 앤티티"의 개념도 주먹구구식으로 이해한 사람이 저걸 어디까지 이해하고나 있을런지. 그 분야에 새끼 발가락이나 하나 걸치고 있다고 누가 좀 좋게 봐줄거라고 생각했나? 어림없는 일일세. 코난의 엄지 발가락이라면 모를까.

앤더슨의 "스케줄러 액티베이션" 논문을 구해서 직접 보니, 구구절절한 상세 매커니즘은 구현하는 사람에게나 필요한 것이지 그것의 전체적인 방법론은 책에서와 같이 한페이지로 충분해보이는군요.

"결국 한페이지 읽어 놓고 스케줄러 액티베이션이 어쩌고 저쩌고하는 전문가 행세를 하셨던 것이었습니다. 전문가가 된다는 게 이렇게 간단하고 쉬웠던 것인가요"

정말이지 꼴갑하는군요. 다시 생각해보니 소설가보단 국회의원이 더 나을 것 같군요.

"그러면 FreeBSD의 커널 스케줄러 엔티티는 kernel supported and multiplexed user-level thread with system-level contention added 모델이라고 하면 맞나요?"

글쎄요. 님의 의식 구조가 상식적이라면야 한번 고려해볼 수도 있겠으나 그렇지 않은 것 같아서리. 어떻든 님 맘대로 생각하세요. 그리고 내가 지어낸 그 말, 그걸 왜 그렇게 말했는지 다시금 생각해보는게 어때요? 누가 자기 비꼬는데, 그것도 이해 못하고, 토를 다는 꼴이 애처롭습니다. 님의 수준이 1차원보다는 높을줄 알았는데 그것도 아니군요.

"허, 제가 3개라고 그랬더니 아니라고 해놓고 나머지는 하이브리드 형태라니 무슨 말씀이세요? "

님을 국회 의원으로 보내고 나서 여의도를 날려버리고 싶군요. 3개, 4개같은게 중요한거였나요? 참나.

커널과 유저 레벨 쓰레드가 있고, 나머지는 하이브리드로 섞어 놓은거고, 그리고 그 하이브리드중 대표적인거 2개를 합쳐서 크게는 4가지인 것입니다. 누군가가 이미 만들어 놓은 두가지의 대표적인 하이브리드를 능가하는 뭔가를 만들면 그 결과 "크게는 5가지"가 되는 것이죠. 이런 말이 님의 의식속으로 침투가 될런지 의문이지만, 님의 의식구조에 담긴 M:N 모델로 보면 무엇이든간에 3개속에 담길 수 밖에 없다는걸 알기에 설득은 생략하죠.

그리고 오해할가봐 말하는건데, M:N 모델이 아니라고 해도 커널 앤티티와 쓰레드간의 바인딩 구조는 오래전부터 알고 있었으니 참고하세요. 커널 앤티티를 "커널에서 보는 쓰레드"로 만들어 사람을 오해의 늪으로 끌어 들이고도 자신의 잘못을 인정하지 않기는 커녕 상대를 깔아 뭉게는데 여념없는 그 집요함에 눌릴 제가 아니지만 독자를 위해 추가했습니다.

"M:N 모델이 제 논리대로 존재하고 있냐고요? 제가 인용한 논문 안읽으셨습니까? 하늘의 해는 하느님의 논리대로 존재하고 있습니까?"

전 M:N 모델을 이해합니다. 그러나 님의 말에 있는 M:N 모델에 대한 언급은 앞에 글에서 지적했듯이 오류가 있습니다. 편안하게 살려면 오류를 인정하고 오해를 풀게 하는게 상호지간 좋을겁니다.

"허, 수준이 좀 높은 분들은 다른 사람 밥먹을 때 "쳐먹어"라고 말하고 싶은 욕구를 느끼기도 하나 봅니다. 뭐 좋습니다. 수준이 높아서 그런건데 제가 뭐라 할 수 있나요."

수준이 높아 봐야 초등학생이죠. 님은 유치원생입니다. 독자분들은 최소 중학생이상일테니 누가 누구를 걱정을 상황은 못됩니다. 상황 파악 좀 하기 바랍니다.

"책을 엉뚱하게 요약해서 오해하셔 놓고는 제가 책 내용 자체를 부정한다니요."

어이가 없군. 코가 이젠 자기 코보다 길어졌겠군. 양심에 찔리지도 않나. 인간 아니 나무가 불쌍합니다. 이러다 인간못될 수도 있어요.

"마이크로소프트웨어 2002년 6월호에서 제가 쓴 글의 참고문헌에 무슨 논문이 나열되어 있는지 확인해 보시죠. 물론 마이크로소프트웨어란 잡지가 있는지조차도 모르고 계실 가능성이 높다고 예상합니다만. "

내가 10년전 초보일때 즐겨 보았던 잡지가 마이크로소프트웨어, 프로그래밍 세계인데, 이걸 들고서 "이것도 모르냐"라고 하니 참 우습군. 마이크로소프트웨어 별로 도움이 안되서 안본지도 몇년 되었는데 이런 잡지에 쓴 글이 머가 그리 대단하다고 이러는건지. 원참. 무료로 아니 돈을 준다해도 안봅니다.

"하하하, 제가 그 논문에 있는 내용 물어볼까 겁이 나셨나봐요. 미리 안읽었다고 선수를 치시는 걸 보면요(퀴즈: 업콜이 뭡니까?). 그런데 스케줄러 액티베이션에 관해 논문 한편도 제대로 안읽고 이렇다 저렇다 논평을 하십니까. "내용을 확 뒤집었다면"이란 뜬금없는 가정은 어떻게 설정하셨는지도 설명해 주시면 감사하겠습니다."

이놈보게. 물어 봐라 이 자식아, 버릇없는 새끼, 도저히 못참겠네. 참는 것도 한계가 있지.
퀴즈에 있는 upcall이란 유저-레벨에서는 커널 함수를 호출하지만 커널 레벨에서는 유저-레벨의 함수를 호출못하는거다. 이유는 유저 함수에서 다시 커널 함수 호출하면 순환 호출(resursion)에 의해 엉망이 될테니.
기껏 묻는다는게 이정도 수준밖에 안되나 이 자식아. 좀 더 어려운거 물어보지? 내가 진짜 모르는걸 하나만 물으면 내가 니 긴 코를 감춰주마.

"자기 잘못은 절대 인정안하시는군요. 분명히 스케줄러 액티베이션은 M:N 모델이 아니라고 주장하시지 않았습니까? "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."의 어느 부분이 해석하기에 곤란합니까? "

말도안되는 M:N model을 말해놓아, 그 기준대로 말할 수 밖에 없었는데, 이제 내 글만 틀렸다라고 하니 지나가는 똥개가 웃겠다 이 새끼야.

"Williams, N., An Implementation of Scheduler Activations on the NetBSD Operating System"에 대해서는 인용하지 마라. 이 새끼야. 이미 다 읽었다. 너의 그 허구와는 달리 잘 써놨더군.

"각각의 커널 엔티티는 실행 컨텍스트를 나타내고, 실행 컨텍스트는 커널 내에서 struct lwp로 표현됩니다. 이제 무슨 뜻인지 아시겠습니까. 커널 엔티티가 무슨 대단하고 설명하기 힘든 존재로 오해하고 계셔서 드리는 말씀입니다"

니 맘대로 생각하고 니 맘대로 찌걸이다 가거라.

"(전략)라고 되어 있나요? 1-on-N 모델의 설명과 혼동이 되셨다면 더 명확하게 정정하겠습니다. "커널 쪽의 하나의 쓰레드와 사용자쪽의 여러 개의 쓰레드가 대응하는 모델을 1-on-N라 한다"

진짜 핵심인 이 부분을, 구렁이 담넘어가듯, 마치 별거 아닌 것처럼 넘어 갈려는 이 교활함, 정말 진짜 상종을 못하겠다. 시팔 똥밟은 셈 치고, 난 그만할란다.

보통의 경우에는 글을 한번 더 읽어 보고, 오타 수정하고 좀 표현이 너무 지나치다 싶으면 편집을 하는데, 이제는 그럴 기분도 아니다. 그냥 난 이쯤해서 글을 접는다.

내가 이성을 잃고 반말했으니, 너도 반발해도 된다. 실컷 하고 가거라.

그리고 부탁하지만 담에 내 글에 절대 댓글 달지 말거라.

참, 그리고 독자 여러분들께는 죄송합니다. 그냥 좋은 부분만 기억해주세요.

위에 두분의 피터지는 thread에 대한 이야기를 보면서 thread에 대한 생각도 정리하고 나름대로 많이 생각해볼수 있었습니다.(으으윽 두통이)
개인적으로 보기에는 용어상의 차이점 때문에 그런것 같은데..
책마다 혹은 os마다 thread나 process혹은 task같은 용어들이 조금이 다르게 표현되는데요.
두분의 대화가 다른 thread를 공부하는 사람들에게는 도움이 될듯한대요
설명하는듯한 대화가 되면 좋을것 같아서 부탁드립니다.
두분다 잘 아시는것 같고 os나 책에서의 표현이 다른것 때문에 발생하는 문제인것 같습니다.
그다지 큰 문제는 아니라고 생각하는데..
부탁드립니다.

관리자인 권순선님께서 딱 한번 더 글쓸 기회를 주신다고 했으니 저도 이번이 마지막입니다.

제 글의 어느 부분에 "인터넷상에서 떠도는 막연한 자료"가 인용되어 있던가요? 스케줄러 액티베이션을 한페이지로 요약한 책을 다시 머릿속으로 요약해서 허튼 주장을 반복하는 것은 님입니다.

제가 쓴 글을 똑바로 읽으시죠. 어느 책이나 시간이 가면 내용중 일부가 더 이상 현실이 아니게 되는 것이 당연한 거 아닌가요. 1970년대 나온 프로그래밍 책을 읽고 "쓰레드가 뭐냐. 그런 건 세상에 없다"고 궤변을 늘어놓는 꼴입니다.

Uresh Vahalia의 Unix Internals란 책의 딱 한 문장만 인용하죠(이 책은 유닉스 운영체제를 다룬 최고의 책중 하나로 평가받고 있지만, 뭐 그것도 "이따위것들" 정도로 매도하신다면 할 말 없습니다):

뭐, 이 책 보시면 아시겠지만 님이 펄쩍 뛰는 "single threaded process"같은 표현도 자주 나옵니다.

yahoo.com 검색 엔진이 Google이란 건 모르고 계셨겠죠. :roll: (하하하, 갑자기 난감해지세요?) 웹서핑을 하질 않으니 하기사 알 턱이 없으시겠지만. "난 Google보다 yahoo.com쓴다" -> 이달의 코메디상감입니다.

NGPT, NPTL 모르고 쓰레드를 논한다니, 공자 맹자 모르고 중국 철학 논하는 꼴이네요. 책 한권 내내 우려먹는 분은 누구였더라...:oops: 이번에는 Open Software Foundation에서 출간한 Mach 3 Kernel Principles에서 한문장 인용할게요:

하하하, 뜨끔하시죠. 뒤에 한두 문장 더 읽어 보면 님이 부정하시는 "single thread"란 표현도 바로 등장합니다.

이제사 읽어보셨군요. 근데 저번 글에서 "저도 직접 읽어보진 않았다"고 하셨는데, 거기서 "도"는 누굴 뜻하는 겁니까? 님이 인용하신 책의 저자들이나 제가 인용한 논문의 저자(Nathan Williams), 그리고 저는 모두 그 논문을 읽어 봤는데 도대체 누가 "도"에 속하는 건지...?

제가 비꼴려고 한말이 님이 또 토를 다시는군요. "울트라 수퍼 하이퍼 메가톤 어쩌고 저쩌고..."가 생각나서 말씀드린 거였습니다. :P

자기가 한말도 자기가 잊어버리십니까. 그대로 인용을 해드릴까요:

누가 스케줄러 액티베이션이 M:N 모델이 아니라고 했더라...저도 기억이 잘 안나네요. :D 또 하나 더 하죠:

첨에는 1:N, 1:1, M:N 모델이 말도 안되는 모델이라고 하다가 이제 슬쩍 인정을 하시는군요.

제가 위에서 인용한 Mach 3 책이나 한번 정독을 해보시면 entity를 어떤 의미로 쓰는지 쉽게 알 수 있으실텐데요. 별것도 아닌 용어를 무슨 대단한양 떠벌리시기는.

"말도 안되는 모델"이라면서요? 설명을 해달라면요? 금방 이해를 하셨나요?

제가 사람을 잘 봤군요. "초등생 수준의 논리적 사고력"을 가진 분이라는걸요. 지금 초등생에 카운터 펀치를 열심히 날리고 있는 중이니 저는 "중학생" 수준은 될 것 같습니다. :wink:

"초보일 때 즐겨 보았던 잡지" -> 이달의 두번째 코메디상감입니다. 마소가 무슨 "PC 사랑"과 같은 종류의 책인줄 아시는군요. 한번도 안 읽어본 게 바로 들통났습니다.

허라, 이제 아주 쌍욕을 대놓고 하시는군요. 욕설을 퍼부으실려면 글 첨부터 하시지 헷갈리게 존대말과 반말을 섞어 쓰고 그러십니까? 뭐 아무튼, 님의 답은 아주 정확히 틀렸습니다. 완전 거꾸로 얘길 하시는군요. Nathan Williams 논문에서 인용하죠:

이번에는 Anderson 논문에서 인용:

사용자 함수에서 커널 함수를 호출하는 걸 "시스템콜"이라고 합니다. 업콜은 커널 함수에서 사용자 함수를 호출하는 겁니다. 하하하, 제가 만든 함정에 딱 빠졌습니다(차라리 대답안했으면 망신 안당했을 텐데~). 정말 님은 "이 정도 수준"도 안되는군요. :roll:

어, 저는 M:N 모델에 대해 길게 설명도 안했는데, 어디서 말이 안되었습니까?

논문 읽느라 주말에 놀지도 못하고 고생좀 하셨겠습니다.

누가 그러더군요. 인터넷에서 헛소리로 욕하는 사람한테는 "반사!"라고 말해주면 된다고요. :lol:

이성을 잃은 건 처음부터 알아봤습니다. 저는 아무리 흥분해도 그정도까지는 안된다고 생각을 하는데요. 근데 웃기는 건, 갑자기 홍길동전이 생각나는 건 왜일까요? 홍판서가 "길동아, 이제 호부호형 하거라. 실컷 하거라"하는데, 길동이가 "싫사옵니다. 제가 왜 호부호형을 하옵니까?" 이러면 홍판서가 얼마나 황당하겠습니까.

제 생각에 이 정도로 망신을 당했으면 Paladin이란 id로는 더이상 글 못 쓸 거 같습니다. 그러니 절대 댓글 달 수도 없겠지요. 그리고 쓴다해도 제가 댓글 달든 말든 무슨 상관입니까. 애시당초 제가 님의 잘못쓴 내용을 지적한 게 열이 받으셨죠?

음, 님이 쓴 내용에 마지막 한가지 더 망신을:

같은 주제를 놓고 NPTL의 개발자인 Ulrich Drepper와 Ingo Molnar는 뭐라고 했을까요:

이제 1:1이 무슨 뜻인지 이해가 되십니까? 두 저자는 님만 빼고 남들은 전부 다 아는, 리눅스 쪽에선 세계 최고의 개발자들입니다.

뭐, 맞는 내용이 있어야 좋은 부분을 기억하지 않겠습니까. :P 아, 한가지, 님덕분에 예전에 읽은 책과 논문들을 다시 꺼내어 검토해본 것이 이번 flamewar의 값진 소득이었습니다. 그점에 감사드립니다.

팔라딘님은 이론(근거)보다 감정을 내세우시고,
방준영님은 논리적 근거와 이론으로 압도하는군요.

결과적으로, 방준영님에게 한표드립니다.
(팔라딘님의 글이 아무리 옳다하더라도(?) 감정을 앞세우면 좋은 인상을 못줄겁니다.)
좋은글 잘 읽었습니다.
저도 열심히 공부해야겠네요... :D

ps. 이글이 올려질라나...?

관리자 권한을 이용하여 강제로 이번 논의를 중단시키게 된 점 대단히
유감스럽습니다만, 글이 계속될 경우 더욱 문제가 커질 수 있을 것이라
판단되어 어쩔 수 없이 답글을 달 수 없도록 설정을 바꾸었습니다.

서로 지식과 정보를 나눔에 있어 기본적인 네티켓은 꼭 지켜 주시기를
바랍니다. 아무리 넓고 깊은 지식이라 할지라도 상대방을 무시하거나
비하하는 태도나 욕설 등이 섞이게 되면 많은 사람들의 눈살을 찌푸리게
하고 인격을 의심하게 만듭니다.

인터넷의 익명성을 악용하여 기본적인 네티켓을 지키지 않는 사용자는
앞으로 상황에 따라 글쓰기 제한이나 강제 퇴출 등의 극단적인 조치를
취할 수도 있습니다. 물론 이런 일이 생기지 않도록 서로 존중하는 태도를
가지는 것이 가장 좋은 일이겠지요? :) 8) :wink: