3. 쓰레드 (1)

[3-1] 프로세스와 쓰레드

 

1. (remind) 프로세스의 두 가지 특성

-자원 소유권 : 프로세스는 자신의 이미지 (프로그램, 데이터, 스택, 속성의 집합) 를 위한 가상 주소 공간을 포함한다

:운영체제는 보호 기능을 수행하여 프로세스들 간에 자원에 대한 불필요한 간섭이 일어나는 것을 막는다.

-스케줄링/수행 : 프로세스 수행은 하나 이상의 프로그램을 통과하는 수행 경로를 따른다 (궤적)

:한 프로세스는 다른 프로세스들과 번갈아가면서 (인터리빙) 수행될 수 있기 때문에, 따라서 프로세스는 수행상태와 디스패칭 우선순위를 가지며, 운영체제에 의해 스케줄되고 디스패치되는 개체이다

 

-이러한 두 가지 특성이 서로 독립적이며 운영체제에 의해서 독립적으로 취급될 수 있음을 알아야 한다.

-이러한 사항은 많은 운영체제에서 적용되는 특성이다. 

-두 가지 특성을 구분하기 위해서, 디스패칭 단위는 쓰레드(thread) 또는 경량 프로세스(lightweight process) 라고 하며, 자원 소유권의 단위는 프로세스 또는 태스크 (task)라고 한다.

 

2. 멀티쓰레딩(Multi-threading)

- 멀티쓰레딩이란, 운영체제가 하나의 프로세스 내에서 수행되는 여러 개의 쓰레드를 지원하는 기능을 말한다.

- 하나의 프로세스 당 하나의 쓰레드가 수행되는 전통적인 방식, 즉 단일 쓰레드 접근방식 (single-thread approach)에서는 쓰레드의 개념이 확실하지 않다

-멀티쓰레드 환경에서 프로세스는 보호의 단위와 자원 할당의 단위로 정의되며, 다음은 프로세스와 연계된 것들이다.

(1) 프로세스의 이미지를 유지하는 가상 주소 공간

(2) 처리기와 다른 프로세스, 파일, 입출력 자원에 대한 접근제어

 

-프로세스는 하나 이상의 쓰레드를 가지며, 각 쓰레드는 다음 사항들을 포함한다

(1) 쓰레드 수행 상태

(2)수행 중이 아닐 때 저장되어있는 쓰레드 문맥

: 쓰레드를 보는 관점 중의 하나는 쓰레드를 한 프로세스 내부에서 동작하는 독립된 프로그램 카운터로 간주하는 것이다.

(3) 수행 스택

(4) 지역 변수 저장을 위해 각 쓰레드가 사용하는 어떤 정적 저장소

(5) 프로세스의 메모리 및 자원에 대한 접근으로, 메모리 및 자원은 프로세스 내의 모든 쓰레드에 의해 공유

 

- 단일 쓰레드 프로세스 모델 (쓰레드에 대한 분명한 개념이 없는 경우)에서, 프로세스는 프로세스 제어블록, 사용자 주소공간, 사용자 스택과 커널 스택 등으로 표현된다.

-스택은 프로세스 수행 중에 함수 호출/복귀 행위를 관리한다.

-한 프로세스가 수행되는 동안 이 프로세스는 처리기 레지스터들을 제어하다. 

-프로세스가 수행 중이 아니면 처리기 레지스터들의 내용은 저장된다.

-멀티쓰레드 환경에서도 프로세스와 관련되어 하나의 프로세스 제어블록과 사용자 주소 공간이 있고, 또한 레지스터 값, 우선순위, 그 외의 쓰레드 관련 상태 정보를 포함하고 있는 별도의 제어블록이 있다.

 

-따라서 프로세스 내의 모든 쓰레드들은 그 프로세스의 상태와 자원을 공유한다. 그 쓰레드들은 같은 주소 공간에 존재하며, 동일한 데이터에 접근한다.

-프로세스 내의 한 쓰레드가 메모리에 있는 데이터 항목을 변경했을 경우, 다른 쓰레드도 그 데이터 항목에 접근하여 그 결과를 확인할 수 있게 되는 것이다.

-만일 하나의 쓰레드가 읽기 권한을 가지고 파일을 개방하면, 같은 프로세스에 있는 다른 쓰레드들도 그 파일을 읽을 수 있다.

 

-성능면에서의 쓰레드의 주된장점

(1) 새로운 프로세스를 생성하는 시간보다, 기존 프로세스 내에서 새로운 쓰레드를 생성하는 시간이 더 짧다

(2) 프로세스 종료시간보다 쓰레드 종료시간이 더 짧다

(3) 프로세스들 간의 교환보다 같은 프로세스에 있는 두 쓰레드 간의 교환이 효율적이다.

(4) 쓰레드는 서로 다른 수행 프로그램 간의 통신에서도 효율적이다.

:대부분의 운영체제에서 독립된 프로세스들간의 통신에는 보호 및 통신 기법을 제공하기 위해 커널이 개입되어야하는데, 이에 반해 같은 프로세스 내의 쓰레드들은 메모리 및 파일을 공유하기 때문에 커널을 호출하지 않고도 서로 통신할 수 있게 된다.

-따라서 연관된 수행단위의 집합으로 구현되어야 하는 응용이나 기능이 있다면, 이들을 독립적인 프로세스가 아닌 쓰레드의 모음으로 구현하는 것이 훨씬 효율적이다.

 

-쓰레드를 활용한 응용의 예시 -> 파일서버

-파일에 대한 요청이 있을 때마다 파일 관리 프로그램은 새로운 쓰레드 형성

-서버는 많은 요청을 처리할 것이므로 짧은 시간 동안 많은 쓰레드가 생성되고 소멸될 것이다.

-서버 응용이 멀티 프로세서 컴퓨터에서 수행된다면, 한 프로세스 내의 여러 쓰레드가 동시에 다른 처리기에서 수행될 수 있으며. 파일의 프로세스들 또는 쓰레드들은 파일 자료를 공유해야 하며, 따라서 그들의 연산을 조정하는 것이 필요하다.

-이의 조정을 위해 프로세스와 메시지 전송을 사용하는 것보다는 쓰레드와 공유 메모리를 사용하는 것이 효율적이다.

 

-논리적으로 여러 가지 다른 기능을 수행하는 특정 프로그램의 구조를 단순화할 수 있다는 면에서 쓰레드 구조는 단일 처리기에서도 유용하다

-단일 사용자 멀티 프로세싱 시스템에서 쓰레드를 사용하는 네 가지 예

(1) 전면(foreground) 와 후면(background) 작업 

: ex) 스프레드 시트 프로그램 -> 하나의 쓰레드가 메뉴를 나타내고 사용자 입력을 읽는 중에, 다른 쓰레드는 사용자 명령을 수행하고 스프레드 시트를 갱신할 수 있다

: 이러한 배정은 프로그램에서 이전 명령이 완료되기 전에 다음 명령을 신속하게 수행함으로써 응용의 속도를 향상시킨다

(2) 비동기 처리 (asynchronous) 

:프로그램의 비동기적 요소들을 쓰레드를 통해 구현할 수 있다.

:ex) 정전으로부터 보호하기 위해 1분마다 메모리 버퍼의 내용을 디스크로 기록하는 워드 프로세서를 설계할 수 있다

: 이를 위한 쓰레드가 생성될 수 있는데, 유일한 업무는 주기적인 백업이며 운영체제를 통해 직접 자신을 스케줄링

: 프로세스 내부에서 내부적으로 생성된 쓰레드이기 때문에, 이때 시간을 검사하거나 또는 입력 및 출력을 조정하기 위해 주 프로그램 내의 복잡한 코드를 작성할 필요가 없게 된다.

(3)빠른 수행

: 멀티쓰레드 프로세스는 어떤 데이터 묶음 (batch)을 계산하면서 동시에 어떤 장치로부터 다음 데이터 묶음을 읽어들일 수 있게 된다 

:멀티 프로세서 시스템에서 한 프로세스 내의 여러 쓰레드들은 실제적으로 동시에 수행될 수 있다.

:따라서 한 쓰레드가 특정 데이터 묶음을 읽기 위해 입출력 작업 완료를 기다리면서 블록될 지라도, 또 다른 쓰레드가 수행될 수 있다.

(4)모듈 프로그램 구조 

: 다양한 활동 혹은 입출력 연산에 대한 다양한 출발 및 목적지를 포함하고 있는 프로그램의 경우, 쓰레드들을 사용하고 설계하고 구현하는 것이 편리하다.

 

-쓰레드를 지원하는 운영체제에서는 스케줄링과 디스패칭이 쓰레드를 기초로 하여 이루어진다.

-따라서 수행에 관련된 대부분의 상태 정보가 쓰레드 수준의 자료구조에 의해 유지된다

-그러나 몇몇 작업들은 프로세스 내의 모든 쓰레드에게 영향을 미치며, 운영체제는 이를 프로세스 수준에서 관리해야 한다.

-ex) 보류 (suspension)은 또 다른 프로세스 주소공간을 확보하기 위해 주기억장치로부터 어떤 프로세스 주소 공간을 스왑아웃하는 것과 관련되어 있다. 한 프로세스 내의 모든 쓰레드는 같은 주소 공간을 공유하기 떄문에, 모든 쓰레드가 동시에 보류상태로 된다.

-이와 유사하게 한 프로세스가 종료되면 그 프로세스 내의 모든 쓰레드도 종료된다.

 

3. 쓰레드 기능

-프로세스처럼 쓰레드도 수행 상태를 가지며 서로 동기화될 수 있다

 

(1)쓰레드 상태

-프로세스 상태와 같이, 각 쓰레드의 주요 상태에는 수행과 준비, 블록이 있다.

-일반적으로 보류 상태는 프로세스 수준의 개념이기 때문에 쓰레드와 연관시키는 것은 의미가 없다.

-특히 프로세스가 주기억장치로부터 스왑아웃될 경우, 그 프로세스의 모든 쓰레드는 주소공간을 공유하기 때문에 모든 쓰레드도 반드시 스왑아웃된다

 

-쓰레드 상태 전이와 관련하여 기본적으로 네 가지의 쓰레드 연산이 존재한다

(i) 생성 (spawn) 

: 일반적으로 새로운 프로세스가 생성되면 이 프로세스를 위한 쓰레드도 함께 생성된다

: 계속해서, 그 쓰레드는 프로세스 내에서 다른 쓰레드를 생성할 수 있으며, 이 경우 새로 생성된 쓰레드를 위하여 명령 포인터와 인자들을 제공한다.

:새로운 쓰레드는 자신의 레지스터 문맥과 스택공간을 가지며 준비 큐에 위치된다.

(ii) 블록 (Block)

: 쓰레드가 어떤 사건을 기다려야 할 때 쓰레드는 블록된다. 이 때 자신의 사용자 레지스터, 프로그램 카운터, 스택포인터를 저장한다.

: 이제 처리기는 동일 프로세스 내에 있거나 또는 다른 프로세스 내에 있는 준비 상태의 다른 쓰레드를 수행할 수 있다

(iii) 비블록 (Unblock) 

:쓰레드가 블록되어 기다리던 사건이 발생했을 때 그 쓰레드는 준비 큐로 이동

(iv)종료 (Finish) 

: 쓰레드가 작업을 완료하면 레지스터 문맥과 스택이 해제된다.

-여기서 주요 논점은, 한 쓰레드 블록이 전체 프로세스 블록을 종료시키는지의 여부이다.

-만일 하나의 쓰레드가 전체 프로세스를 블록시킨다면 쓰레드가 지닌 장점과 유연성이 사라지게 된다.

-단일 처리기에서는 멀티 프로그래밍으로 인해, 여러 프로세스 내의 여러 쓰레드들이 번갈아가며 수행될 수 있다. 

-수행 중인 쓰레드가 블록되거나 정해진 시간 할당량을 모두 소비하면 수행 흐름은 한 쓰레드에서 다른 쓰레드로 넘어감

 

(2) 쓰레드 동기화

-프로세스 내의 모든 쓰레드는 주소공간과 열린 파일과 같은 자원을 공유한다.

-하나의 쓰레드에 의한 자원의 변경은 같은 프로세스 내에 존재하는 모든 쓰레드의 환경에 영향을 미친다.

-따라서 쓰레드들이 서로 간섭하지 않도록, 또는 자료구조를 손상시키지 않도록 쓰레드들의 행위를 동기화하는 것이 필요하다.

-예를 들어 두 쓰레드가 각각 따로 이중 연결 리스트를 어떤 요소에 동시에 추가하려고 한다면, 하나의 요소가 분실되거나 리스트가 비정상적인 행태로 구성이 될 수 있다.

-쓰레드 동기화에서 발생하는 논점 및 사용되는 기술은 일반적으로 프로세스 동기화에서 생기는 논점이나 기술과 같다 

-따라서 추후 학습 예정이다.

 

 

[3-2] 쓰레드의 유형

 

1. 사용자 수준의 쓰레드와 커널 수준의 쓰레드

: 쓰레드 구현에는 사용자 수준 쓰레드 (ULT: user-level thread) 와 커널 수준 쓰레드 (KLT: kernel-level thread) 두 가지의 범주가 존재한다. 다른 문헌에서는 커널 수준의 쓰레드를 커널-지원 쓰레드, 혹은 경량 프로세스라고 부르기도 한다.

 

(1) 사용자 수준 쓰레드 (ULT)

-순수한 ULT 구현에서, 쓰레드 관리와 관계된 모든 일은 응용이 수행하며 커널은 쓰레드의 존재를 알지 못 한다.

-ULT 관리 루틴들로 구성된 패키지인 쓰레드 라이브러리를 이용하여, 모든 응용을 멀티 쓰레드 기반으로 프로그래밍 할 수 있다.

-쓰레드 라이브러리는 쓰레드의 생성과 제거, 쓰레드 간의 메시지와 데이터 전달, 쓰레드 수행과 스케줄링, 쓰레드 문잭의 저장과 복구 등을 위한 코드를 포함한다.

 

-기본적으로 응용은 시작하자마자 하나의 쓰레드를 가지며, 그 첫 쓰레드에서 수행을 시작한다.

-이 응용과 쓰레드는 커널에 의해서 관리되는 하나의 프로세스에 할당된다.

-응용이 수행되는 도중 어느 때라도, 응용은 새로운 쓰레드를 생성하여 같은 프로세스 내에서 수행할 수 있다.

-쓰레드 생성은 쓰레드 라이브러리 내의 생성 유틸리티 (spawn utility) 를 호출하여 이루어진다.

-프로시저 호출에 의해 제어는 그 유틸리티로 넘어가고, 쓰레드 라이브러리는 새로운 쓰레드를 위한 자료구조를 생성한 다음, 스케줄링 알고리즘을 사용하여 프로세스 내에서 준비상태에 있는 한 쓰레드로 제어를 넘겨준다.

-제어가 현재 쓰레드로부터 라이브러리로 넘어갈 때는 현 쓰레드의 문맥이 저장되고, 제어가 라이브러리로부터 어떤 쓰레드로 넘어갈 때에는 해당 쓰레드의 문맥이 복구된다.

-문맥은 본질적으로 사용자 레지스터의 내용, 프로그램 카운터, 스택 포인터 등으로 구성된다.

-이 모든 작업은 사용자 공간과 단일 프로세스 내에서 이루어지며, 커널은 이러한 작업을 전혀 알지 못 한다.

-커널은 계속하여 프로세스 단위로 스케줄하며, 그 프로세스에게 어떤 수행 상태를 할당한다. 

 

-예시 ) 프로세스 B가 자신의 쓰레드 2에서 수행 중, 프로세스 B와 그 ULT의 상태

: 발생 가능한 상황은 다음 중 하나이다.

(i) 쓰레드 2에서 수행 중인 응용이 B를 블록시키는 시스템 호출(입출력 호출과 같은) 을 수행한다

:이때 제어는 커널로 넘어가게 되어, 커널은 입출력 작업을 시작하고, 프로세스 B를 블록 상태에 놓은 다음, 다른 프로세스로 교환한다.

:한편 쓰레드 라이브러리에 의해 관리되는 자료구조에 의해 프로세스 B의 쓰레드 2는 여전히 수행상태에 있다.

:쓰레드 라이브러리에 의해 수행 상태에 있는 것으로 인식되는 것이다.

:이에 대응하는 상태 전이도가 (b)에 나타나있다.

(ii) 클록 인터럽트로 인해 제어가 커널로 넘어가고, 커널은 현재 수행 중인 프로세스 (B)가 자신의 시간 할당량을 다 소모하였다고 판단

:커널은 프로세스 B를 준비상태로 놓고 다른 프로세스로 교환한다.

:한쳔 쓰레드 라이브러리가 관리하는 자료구조에 의하면 프로세스 B의 쓰레드 2는 여전히 수행상태에 있다.

-이에 대응하는 상태 전이도가 (c)에 나타나 있다.

(iii)쓰레드 2는 프로세스 B의 쓰레드 1에 의해 수행 될 어떤 연산을 필요로 하는 지점에 도달

:블록 상태에 들어가게 되며, 쓰레드 1이 준비 상태에서 수행 상태로 전이된다.

:프로세스 B는 여전히 수행 상태에 있다.

: 이에 대응하는 상태 전이도는 (d)에 나타나있다.

 

-위의 첫 번째 경우와 두 번째 경우일 때에는, 커널이 제어를 프로세스 B에 넘기면 쓰레드 2에서 수행이 재개된다.

-또한 프로세스는 쓰레드 라이브러리의 코드를 수행하는 동안, 시간 할당량을 다 소모하면 인터럽트 될 수 있으며, 또한 더 높은 우선순위를 가진 프로세스에 의해 선점되는 경우에도 인터럽트 될 수 있다.

-따라서 어떤 프로세스는 한 쓰레드에서 다른 쓰레드로 쓰레드 교환이 발생하는 도중에 인터럽트가 될 수도 있다.

-이 프로세스가 재개되면 쓰레드 라이브러리에서 수행이 계속되며, 이 떄 쓰레드 라이브러리는 쓰레드 교환을 완료하고 그 프로세스 내외 새로운 쓰레드에게 제어를 넘기게 된다.

 

-ULT를 사용하면 다음과 같은 장점이 있다

(i) 쓰레드 관리를 위한 모든 자료구조가 프로세스의 사용자 주소 공간에 있기 때문에 쓰레드 교환에 커널 모드의 권한이 요구되지 않는다.

:따라서 프로세스는 쓰레드 관리를 위해 커널 모드로 전환될 필요가 없다.

:이는 두 모드 사이의 전환 시 발생할 수 있는 오버헤드를 절감시켜 준다.

(ii)스케줄링이 응용에 맞게 구성될 수 있다.

:어떤 응용의 경우 라운드로빈 스케줄링 알고리즘이 가장 효율적일 수 있고, 다른 응용의 경우 우선순위 기반 스케줄링 알고리즘이 가장 효율적일 수 있다.

:기반이 되는 운영체제 스케줄러에 영향을 미치지 않고, 스케줄링 알고리즘을 응용에 맞출 수 있다.

(iii) ULT 는 어떠한 운영체제에서도 적용될 수 있다.

: ULT를 지원하기 위해 기본 커널을 변경할 필요가 없어진다.

: 쓰레드 라이브러리는 모든 응용이 공유하는 응용-수준 함수들의 집합이다.

 

-KLT와 비교하여 ULT의 단점

(i) 일반 운영체제에서 대부분의 시스템 호출은 해당 쓰레드를 블록시킨다.

: 결과적으로 쓰레드가 시스템 호출을 수행할 경우 그 쓰레드 뿐만 아니라 같은 프로세스 내에 있는 모든 쓰레드가 블록된다.

(ii) 순수한 ULT 기반의 멀티 쓰레드 응용은 멀티프로세싱의 장점을 살릴 수 없다.

: 커널은 한 번에 하나의 프로세스를 할당하기 때문에, 임의 시점에 단일 프로세스 내에서 하나의 쓰레드 만을 수행할 수 있게 된다.

: 사실상 단일 프로세스 내에서 응용 수준의 멀티 프로그래밍이 이루어진다.

:이러한 멀티 프로그래밍으로 인해 한 응용의 수행 속도를 상당히 향상시킬 수 있는 반면에, 어떤 응용들은 코드의 부분들을 동시에 수행함으로써 이익을 얻을 수도 있다.

 

-단점 해결방법

-예를 들어 응용을 멀티 쓰레드 대신 멀티 프로세스로 작성함으로써 문제를 해결할 수 있다.

-그러나 이러한 시도는 쓰레드의 중요한 장점을 살리지 못 한다.

-쓰레드 교환 대신 프로세스 교환을 함으로써 각 교환마다 오버헤드가 증가하게 되는 것이다.

-블록형 시스템 호출에서 프로세스 내의 모든 쓰레드를 블록시키는 문제를 해결하기 위한 방법으로 자켓팅(jacketing)이라는 기술을 활용할 수도 있다.

-자켓팅의 목적은 블록형 시스템 호출을 비블록형 시스템 호출로 변환하는 것이다.

-예를 들어 쓰레드는 시스템 입출력 루틴을 직접 호출하기 보다 응용 수준의 입출력 자켓 루틴을 호춣ㄴ다.

-자켓 루틴 내에는 입출력 장치가 사용 중인지 검사하는 코드가 이싿.

-입출력 장치가 사용 중이면 쓰레드는 블록 상태로 들어가게 되고, 제어를 다른 쓰레드로 넘긴다.

-이 쓰레드가 나중에 제어를 다시 넘겨받으면, 그 자켓 루틴이 입출력 장치를 다시 검사한다.

 

 

(2) 커널 수준 쓰레드 (KLT)

- 순수한 KLT 구현에서는 쓰레드 관리와 관련된 모든 작업이 커널에 의해 이루어진다.

-응용 영역에는 쓰레드 관리를 위한 코드가 없고 단순히 커널 쓰레드 기능에 대한 API(응용 프로그래밍 인터페이스)가 존재한다.

-Windows가 대표적인 예시이다.

-이 중 (b)는 순수한 KLT 방식을 보여준다. 

-커널은 전체 프로세스에 대한 문맥 정보 및 각 프로세스 내 쓰레드에 대한 문맥 정보를 유지한다.

-커널에 의한 스케줄링은 쓰레드를 기반으로 해서 이루어진다.

-이러한 접근 방법을 사용하여 ULT의 주된 단점 두 가지를 극복한다.

(i) 커널은 여러 처리기에게 같은 프로세스 내의 여러 쓰레드를 동시에 스케줄 할 수 있다.

(ii) 한 프로세스의 쓰레드가 블록되면 커널은 같은 프로세스에서 다른 쓰레드를 스케줄할 수 있다.

-KLT의 다른 장점은 커널 루틴 자체가 멀티쓰레드로 구성될 수 있다는 것이다.

-KLT의 주된 단점은 같은 프로세스 내의 한 쓰레드에서 다른 쓰레드로 제어를 넘길 때, 커널로의 모드 전환이 필요하다는 것이다.

-모드 전환으로 인한 오버헤드를 피할 수 없다는 것이다.

 

-따라서 단일 쓰레드 프로세스와 비교해 볼 때 KLT 멀티 쓰레드를 사용함으로써 속도 향상이 가능하고, ULT를 이용하면 추가적인 속도 향상이 가능하다.

-그러나 실제로 추가적인 속도 향상이 실현될 지에 대한 여부는 응용의 특성에 달려있다.

-만일 응용에서 대부분의 쓰레드 교환이 커널 모드 접근을 요구한다면, ULT를 기반으로 하는 구조는 KLT를 기반으로 하는 구조보다 훨씬 좋은 성능을 내지 못 할 수도 있다.

 

(3) 결합된 접근 방법

-어떤 운영체제는 ULT 와 KLT 구현이 결합된 형태를 제공한다. 그림 (c)가 이에 대한 정보이다.

-결합된 방법을 적용하는 시스템에서 쓰레드 생성은 완전히 사용자 공간에서 이루어지며, 한 응용 내의 쓰레드들에 대한 스케줄링 및 동기화 화도 대부분 사용자 공간에서 이루어진다.

아 몰랑

 

2. 다른 배합

-지금까지 논의되었듯이 전통적으로 자원 할당과 디스패칭 단위의 개념은 단일 프로세스 개념, 즉 프로세스와 쓰레드 간의 일대일 관계로 구체화되어왔다.

- 최근에 단일 프로세스에서 여러 쓰레드를 제공하는 다대일 관계에 관심이 높아졌지만, 다대다 관계와 일대 다 관계 등 다른 두 가지 조합 또한 연구가 진행되고 있다.

쓰레드 : 프로세스	설명	시스템 예
1:1	수행 중인 각 쓰레드는 자신의 주소 공간과 자원을 갖는 유일한 프로세스이다.	대부분의 UNIX 시스템
M:1	프로세스는 주소 공간과 동적인 자원 소유권을 정의하며, 여러 쓰레드가 이 프로세스 내에서 생성 및 수행될 수 있다.	Windows, Solaris, Linux...
1:M	쓰레드는 한 프로세스 환경에서 다른 프로세스 환경으로 이동할 수 있다 이것은 쓰레드가 다른 시스템 간을 쉽게 이동할 수 있도록 해 준다.	Ra (Clouds), Emerald
M:N	1:M과 M:1의 특성을 혼합한 것이다.

 

(1) 다대다 관계

- 프로세스와 쓰레드 간에 다대다 관계를 갖게 하는 시도는 실험적 운영체제인 TRIX 에서 연구되었다.

-TRIX는 도메인(domain)과 쓰레드 개념이 있다

-도메인은 주소 공간과 포트 (port)로 구성된 정적 개체로, 포트를 통해 메시지를 주고 받을 수 있다.

-각 쓰레드는 수행스택, 프로세스 상태, 스케줄링 정보를 가지는 단일 수행 경로이다.

 

-지금까지 논의한 멀티쓰레딩 접근 방법에서 볼 때, 다수의 쓰레드들이 이전에 언급했던 효율성을 제공하며 하나의 도메인 안에서 수행될 수 있다.

-또한 단일 사용자의 활동(또는 응용)은 다수의 도메인에서 수행될 수도 있다.

-이러한 경우 쓰레드는 한 도메인에서 다른 도메인으로 이동할 수 있다.

 

-다수의 도메인에서 단일 쓰레드를 사용하는 주된 동기는 프로그래머에게 구조화 도구를 제공하고자 하는 의도로 보인다.

-예를 들어 입출력 서브프로그램을 사용하는 프로그램을 생각해 보자.

-사용자가 프로세스를 생성할 수 있는 멀티 프로그래밍 환경에서, 메인 프로그램은 입출력을 처리하기 위한 프로세스를 생성한 다음, 수행을 계속 진행할 수 있다.

-하지만 메인 프로그램의 향후 진척 과정이 입출력 연산의 결과에 의존한다면, 메인 프로그램은 입출력 프로그램이 끝날 때까지 기다려야만 할 것이다.

 

-응용의 구현 방식

(1)전체 프로그램이 하나의 프로세스로 구현될 수 있다

: 이는 합리적이고 직관적인 해결책이나, 메모리 관리와 관계된 단점이 존재한다.

: 효과적인 수행을 위해 전체 프로세스가 상당량의 메모리를 요구할 수 있는 반면, 입출력 서브 프로그램은 입출력을 버퍼링하고 또한 상대적으로 작은 분량의 프로그램 코드를 처리하기 위해 비교적 작은 주소 공간을 요구한다.

:입출력 프로그램이 자신보다 더 큰 프로그램의 주소공간에서 수행되기 때문에, 입출력 연산 도중 전체 프로세스가 주기억장치에 남아 있어야 하거나 입출력 연산은 스와핑 되기 쉽다.

:메모리 관리와 관련된 이러한 결과는 주 프로그램과 입출력 서브 프로그램이 같은 주소 공간에 두 개의 쓰레드로 구현될 때도 발생 가능하다

(2) 메인 프로그램과 입출력 서브 프로그램은 두 개의 분리된 프로세스로 구현될 수 있다.

: 이는 종속(subordinate) 프로세스 생성으로 인한 오버헤드를 유발시킨다

: 입출력을 자주하게 되면 종속 프로세스를 존속시키거나 서브 프로그램을 자주 생성하고 소멸시켜야 한다

(3)메인 프로그램과 입출력 서브 프로그램을 단일 쓰레드에 의해 처리되는 단일 작업으로 취급할 수 있다

: 하지만 메인 프로그램을 위해서 하나의 주소공간을 생성하고 입출력 서브 프로그램을 위해서 또 다른 주소공간을 생성할 수 있다.

:즉, 쓰레드는 수행 중 두 주소공간을 이동할 수 있다.

: 운영체제는 두 주소공간을 독립적으로 관리할 수 있고 프로세스 생성에 따른 오버헤드는 발생하지 않는다.

: 더 나아가 입출력 서브 프로그램에 의해 사용되는 주소공간이 다른 간단한 입출력 프로그램에 의해 공유될 수 있다.

-> 세 번째 방법이 장점을 가짐, 가장 효율적

 

(2) 일대다 관계

-(분산 컴퓨터시스템을 제어하기 위해서 설계된) 분산 운영체제 분야에서는 주소 공간 사이를 옮겨다닐 수 있는 주요 개체로서 쓰레드 개념이 관심을 쓸어왔다.

-이와 관련된 연구 중 주목할 만한 예가 Clouds 운영체제, 특히 Ra로 알려진 그 커널이다.

-Clouds에서 쓰레드는 사용자 관점에서 본 작업 단위이다.

-프로세스는 프로세스 제어블록을 가지는 가상 주소 공간이다.

-쓰레드는 생성되자마자 프로세스 내에서 프로그램의 시작점을 호출함으로써 수행을 시작한다

-쓰레드는 한 주소공간에서 다른 주소공간으로 이동할 수 있으며, 실제적으로 컴퓨터 경계에 걸쳐있다.

-쓰레드가 이동할 때, 쓰레드는 제어터미널, 전역매개변수, 스케줄링 기준과 같은 정보를 가지고 이동해야 한다.

 

-Clouds는 사용자들과 프로그래머들이 분산 환경의 세부 사항에 대해 독립성을 갖도록 하는 효과적인 방법을 제공한다

-사용자의 작업은 단일 쓰레드로 표현될 수 있으며, 컴퓨터들 간 쓰레드 이동은 원격 자원 접근이나 부하 균형과 같이 시스템과 관련된 다양한 이유로 운영체제에 의해 주도된다.