사용자 수준 스레드와 커널 지원 스레드의 차이점은 무엇입니까?

사용자 수준 스레드와 커널 지원 스레드의 차이점은 무엇입니까?

---

이 주제를 기반으로 몇 가지 참고 사항을 살펴 보았으며 일반적으로 스레드에 대해 이해하고 있지만 사용자 수준 스레드와 커널 수준 스레드 의 차이점 에 대해서는 확신 할 수 없습니다 .

프로세스가 기본적으로 여러 스레드 또는 단일 스레드로 구성된다는 것을 알고 있지만 이러한 스레드는 앞서 언급 한 두 가지 유형의 스레드입니까?

내가 이해 한 바에 따르면 커널 지원 스레드는 시스템 호출 및 사용자 수준 스레드에서 사용할 수없는 기타 용도를 위해 커널에 액세스 할 수 있습니다.

그렇다면 사용자 수준 스레드는 커널 지원 스레드를 사용하여 상태로 인해 정상적으로 수행 할 수없는 작업을 수행 할 때 프로그래머가 만든 스레드일까요?

---

편집 : 질문이 약간 혼란스러워서 두 가지 다른 방법으로 대답하고 있습니다.

OS 수준 스레드 대 녹색 스레드

명확성을 위해 일반적으로 "커널 수준 스레드"대신 "OS 수준 스레드"또는 "기본 스레드"라고 말합니다 (아래 원래 답변에서 "커널 스레드"와 혼동 함). OS 수준 스레드는 다음에서 생성 및 관리됩니다. OS. 대부분의 언어는이를 지원합니다. (C, 최근 Java 등) 문제 예방에 100 % 책임이 있기 때문에 사용하기 매우 어렵습니다. 일부 언어에서는 기본 데이터 구조 (예 : 해시 또는 사전)도 추가 잠금 코드없이 손상됩니다.

OS 스레드의 반대는 사용자 언어로 관리되는 녹색 스레드 입니다. 이 스레드는 언어에 따라 다양한 이름이 지정됩니다 (C의 코 루틴, Go의 고 루틴, Ruby의 섬유 등). 이 스레드는 OS가 아닌 언어 내부에만 존재합니다. 언어가 컨텍스트 전환을 선택하기 때문에 (즉, 문 끝에서) 미묘한 경쟁 조건 (예 : 부분적으로 복사 된 구조를 보거나 대부분의 데이터 구조를 잠글 필요가 있음)의 TONS를 방지합니다. 프로그래머는 "차단"호출 (예 :)을 보지만 data = file.read()언어는이를 OS에 대한 비동기 호출로 변환합니다. 그런 다음 언어 는 결과를 기다리는 동안 다른 녹색 스레드가 실행되도록 허용 합니다.

녹색 스레드는 프로그래머에게 훨씬 더 간단하지만 성능은 다양합니다. 스레드가 많으면 녹색 스레드가 CPU와 RAM 모두에 더 좋을 수 있습니다. 반면에 대부분의 녹색 스레드 언어는 다중 코어를 활용할 수 없습니다. (더 이상 단일 코어 컴퓨터 또는 전화를 구입할 수 없습니다!). 그리고 잘못된 라이브러리는 차단 OS 호출을 수행하여 전체 언어를 중지 할 수 있습니다.

두 세계의 장점은 CPU 당 하나의 OS 스레드와 마법처럼 OS 스레드로 이동되는 많은 녹색 스레드를 갖는 것입니다. Go 및 Erlang과 같은 언어가이를 수행 할 수 있습니다.

사용자 수준 스레드에서 사용할 수없는 시스템 호출 및 기타 용도

이것은 절반에 불과합니다. 예, OS를 직접 호출하면 (예 : 차단하는 작업을 수행하면) 쉽게 문제를 일으킬 수 있습니다. 그러나 언어에는 대개 대체 항목이 있으므로 눈치 채지 못합니다. 이러한 대체는 생각과는 약간 다르게 커널을 호출합니다.

커널 스레드와 사용자 스레드

편집 : 이것은 내 원래 대답이지만 사용자 공간 스레드와 커널 전용 스레드에 관한 것입니다. (돌아 보면) 아마도 질문이 아니 었습니다.

사용자 스레드와 커널 스레드는 정확히 동일합니다. (/ proc /를 보면 커널 스레드도 있음을 알 수 있습니다.)

사용자 스레드는 사용자 공간 코드를 실행하는 스레드입니다. 그러나 언제든지 커널 공간을 호출 할 수 있습니다. 높은 보안 수준에서 커널 코드를 실행하더라도 여전히 "사용자"스레드로 간주됩니다.

커널 스레드는 커널 코드 만 실행하고 사용자 공간 프로세스와 관련이없는 스레드입니다. 커널 전용 데몬이라는 점을 제외하면 "UNIX 데몬"과 같습니다. 따라서 커널이 다중 스레드 프로그램이라고 말할 수 있습니다. 예를 들어, 스왑을위한 커널 스레드가 있습니다. 이렇게하면 모든 스왑 문제가 단일 스트림으로 "직렬화"됩니다.

사용자 스레드에 무언가가 필요하면 커널을 호출하여 해당 스레드를 휴면 상태로 표시합니다. 나중에 스왑 스레드는 데이터를 찾아 사용자 스레드를 실행 가능으로 표시합니다. 나중에 "사용자 스레드"는 아무 일도 일어나지 않은 것처럼 커널에서 다시 사용자 영역으로 돌아갑니다.

실제로 clone () 작업이 커널 공간에서 발생하기 때문에 모든 스레드가 커널 공간에서 시작됩니다. (그리고 사용자 공간에서 새로운 프로세스로 '돌아 가기'전에해야 할 많은 커널 계정이 있습니다.)

---

비교하기 전에 먼저 스레드가 무엇인지 이해합시다. 스레드는 독립 프로세스 도메인 내의 경량 프로세스입니다. 프로세스가 무겁고 많은 리소스를 소비하고 더 중요한 것은

두 개의 개별 프로세스는 메모리 공간을 공유 할 수 없습니다.

텍스트 편집기를 연다 고 가정 해 보겠습니다. 별도의 주소 지정 가능 위치를 사용하여 메모리에서 실행되는 독립적 인 프로세스입니다. 그래픽 삽입, 맞춤법 검사 등과 같은 많은 리소스가이 프로세스에 필요합니다. 이러한 각 기능에 대해 별도의 프로세스를 만들고 메모리에서 독립적으로 유지하는 것은 불가능합니다. 이를 피하기 위해

단일 프로세스 내에서 여러 스레드를 만들 수 있으며, 이는 프로세스 내에서 독립적으로 존재하는 공통 메모리 공간을 공유 할 수 있습니다.

이제 한 번에 하나씩 질문으로 돌아갑니다.

사용자 수준 스레드와 커널 수준 스레드의 차이점에 대해 잘 모르겠습니다.

스레드는 실행 도메인에 따라 사용자 수준 스레드 와 커널 수준 스레드 로 광범위하게 분류됩니다 . 하나 이상의 사용자 스레드가 하나 이상의 커널 스레드에 매핑되는 경우도 있습니다 .

-사용자 수준 스레드

사용자 수준 스레드는 대부분 응용 프로그램이 주 메모리에서 실행을 유지하기 위해 이러한 스레드를 만드는 응용 프로그램 수준에 있습니다. 필요하지 않은 경우 이러한 스레드는 커널 스레드와 격리되어 작동합니다.

많은 레지스터를 참조 할 필요가없고 컨텍스트 전환이 커널 수준 스레드보다 훨씬 빠르기 때문에 생성하기가 더 쉽습니다.

사용자 수준 스레드는 대부분 응용 프로그램 수준에서 변경을 일으킬 수 있으며 커널 수준 스레드는 자체 속도로 계속 실행됩니다.

-커널 수준 스레드

이러한 스레드는 대부분 진행중인 프로세스와 독립적이며 운영 체제에서 실행됩니다.

이러한 스레드는 메모리 관리, 프로세스 관리 등과 같은 작업을 위해 운영 체제에 필요합니다.

이러한 스레드는 운영 체제에 필요한 프로세스를 유지 관리, 실행 및보고하기 때문에; 커널 수준 스레드는 만들고 관리하는 데 더 비싸고 이러한 스레드의 컨텍스트 전환 속도가 느립니다.

대부분의 커널 수준 스레드는 사용자 수준 스레드에 의해 선점 될 수 없습니다.

MS DOS written for Intel 8088 didn't have dual mode of operation. Thus, a user level process had the ability to corrupt the entire operating system.

-커널 스레드에 매핑 된 사용자 수준 스레드

이것은 아마도 가장 흥미로운 부분 일 것입니다. 많은 사용자 수준 스레드는 커널 수준 스레드에 매핑되며, 이는 차례로 커널과 통신합니다.

눈에 띄는 매핑 중 일부는 다음과 같습니다.

1-1

하나의 사용자 수준 스레드가 하나의 커널 스레드에만 매핑되는 경우.

advantages: each user thread maps to one kernel thread. Even if one of the user thread issues a blocking system call, the other processes remain unaffected.

disadvantages: every user thread requires one kernel thread to interact and kernel threads are expensive to create and manage.

Many to One

When many user threads map to one kernel thread.

advantages: multiple kernel threads are not required since similar user threads can be mapped to one kernel thread.

disadvantage: even if one of the user thread issues a blocking system call, all the other user threads mapped to that kernel thread are blocked.

Also, a good level of concurrency cannot be achieved since the kernel will process only one kernel thread at a time.

Many to Many

When many user threads map to equal or lesser number of kernel threads. The programmer decides how many user threads will map to how many kernel threads. Some of the user threads might map to just one kernel thread.

advantages: a great level of concurrency is achieved. Programmer can decide some potentially dangerous threads which might issue a blocking system call and place them with the one-to-one mapping.

disadvantage: the number of kernel threads, if not decided cautiously can slow down the system.

The other part of your question:

kernel-supported threads have access to the kernel for system calls and other uses not available to user-level threads.

So, are user-level threads simply threads created by the programmer when then utilise kernel-supported threads to perform operations that couldn't be normally performed due to its state?

Partially correct. Almost all the kernel thread have access to system calls and other critical interrupts since kernel threads are responsible for executing the processes of the OS. User thread will not have access to some of these critical features. e.g. a text editor can never shoot a thread which has the ability to change the physical address of the process. But if needed, a user thread can map to kernel thread and issue some of the system calls which it couldn't do as an independent entity. The kernel thread would then map this system call to the kernel and would execute actions, if deemed fit.

---

Some development environments or languages will add there own threads like feature, that is written to take advantage of some knowledge of the environment, for example a GUI environment could implement some thread functionality which switch between user threads on each event loop. A game library could have some thread like behaviour for characters. Sometime the user thread like behaviour can be implemented in a different way, for example I work with cocoa a lot, and it has a timer mechanism which executes your code every x number of seconds, use fraction of a seconds and it like a thread. Ruby has a yield feature which is like cooperative threads. The advantage of user threads is they can switch at more predictable times. With kernel thread every time a thread starts up again, it needs to load any data it was working on, this can take time, with user threads you can switch when you have finished working on some data, so it doesn't need to be reloaded. I haven't come across user threads that look the same as kernel threads, only thread like mechanisms like the timer, though I have read about them in older text books so I wonder if they were something that was more popular in the past but with the rise of true multithreaded OS's (modern Windows and Mac OS X) and more powerful hardware I wonder if they have gone out of favour.

---

user Threads: 1. The library provides support for thread creation, scheduling and management with no support from the kernel. 2. The kernel unaware of user-level threads creation and scheduling are done in user space without kernel intervention. 3. User-level thread are generally fast to create and manage they have drawbacks however. 4. If the kernel is single-threaded, then any user-level thread performing a blocking system call will cause the entire process to block, even if other threads are available to run within the application. 5. User-thread libraries include POSIX Pthreads, Mach C-threads, and Solaris 2 UI-threads.

Kernel threads: 1. The kernel performs thread creation, scheduling, and management in kernel space. 2. kernel threads are generally slower to create and manage than are user threads. 3. the kernel is managing the threads, if a thread performs a blocking system call. 4. A multiprocessor environment, the kernel can schedule threads on different processors. 5.including Windows NT, Windows 2000, Solaris 2, BeOS, and Tru64 UNIX (formerlyDigital UN1X)-support kernel threads.

참고URL : https://stackoverflow.com/questions/15983872/difference-between-user-level-and-kernel-supported-threads