Process abstraction 문서 원본 보기

[[분류:스레드/프로세스]]

==개요==
프로세스 추상화는 [[Isolation]], [[Protection]], 그리고 실행의 [[추상화]]이다. 메모리 분리, 권한 분리, 그리고 여러 다른 프로그램의 동시 실행을 보장하기 위해서 Modern operating system들은 기본적으로 Process abstraction을 [[운영체제]]의 기본 설계 디자인에 포함하고 있다.

프로세스 추상화는 위의 이점을 제공하기도 하나, [[Context switching]], [[IPC]], [[Scheduler]], [[Resource accounting]]과 같은 오버헤드를 동반한다. 특히 대부분의 오버헤드를 차지하는 것은 커널 [[소프트웨어]] 파트로, [[하드웨어]]부분도 일정 오버헤드가 일어나기는 하나, 소프트웨어 파트에 비하면 크게 작다.

따라서 컴퓨팅 시스템 연구에서는 Process abstraction의 한계를 극복하기 위한 다양한 연구들이 수행되고 있다. 본 문서는 이러한 연구를 정리한다.

==연구 방향==
===Protection===
Protection을 위한 방식은 크게 2가지로 분류 가능하다. [[Operating System Support for Safe and Efﬁcient Auxiliary Execution|Orbit]]에서는 추가로 Maintenance라는 Protection senario를 추가하였다.

*Extensibility: Application의 기능 확장을 하는 Extenstion을 안전하게 분리하여 실행시키기 위한 방법으로 [[SFI]]와 같은 방식이 사용된다. 
**대표적인 연구로 [[NaCL]]을 들 수 있다. E.g., User-defined function, Browser extension 등등
*Secure partition: Application의 일부분을 Main logic과 분리하여 안전하게 실행하기 위한 방법으로 분리되는 부분은 Application의 기능중 Secure sensitive한 부분이 된다. 
**대표적인 연구로 [[Wedge]]나 [[LwC]]가 있다. E.g., Session handler, Key signing 등등
*Maintenance (Auxiliary tasks): Application과는 독립적으로 실행되나, Application의 State를 감시하고 유지 보수하기 위해서 필요한 기능들을 분리하여 안전하게 실행시키기 위한 방법이다. 
**Orbit이 제한한 개념이다. E.g., Fault Detection, Performance Monitor, Resource Management, Recovery 등등

==연구 정리==
{| class="wikitable"
|+
!Research
!Protection
!Isolation
!First-class
!Observability
!Transparent
!Usages
!Fault recovery
!Performance overhead
!Memory model
|-
|[[Light-Weight Contexts: An OS Abstraction for Safety and Performance|LwC]]
|O
|O
|O
|X
|X
|Secure partition
|Snapshot
|Low
|CoW
|-
|[[Operating System Support for Safe and Efﬁcient Auxiliary Execution|Orbit]]
|O
|O
|O
|O
|X
|Maintenance
|MVCC
|Low
|CoW
|-
|[[Wedge: Splitting Applications into Reduced-Privilege Compartments|Wedge]]
|O
|O
|X
|X
|△
|Secure partition
|X
|Moderate
|Tagged-memory
|-
|[[Process|Process (fork)]]
|O
|O
|O
|O
|O
|Genernal
|X
|None
|CoW
|-
|[[POSIX Threads|Pthread]]
|X
|X
|O
|O
| O
|Genernal 
|X
|None
|Shared
|-
|NaCL
|O
| O
|X
|X
|O
|Extensibility
|X
|High 
|Sandboxing
|-
|Trellis 
|
|
|
|
|
|
|
|
|
|-
|SASOS
|
|
|
|
|
|
|
|
|Capability
|-
|Mondrix
|
|
|
|
|
|
|
|
|
|}

*Protection: 권한 분리를 통해서 서로다른 Abstraction들이 임의로 접근하거나 프로그램의 상태를 변경시키는 것을 막는가?
* Isolation: 메모리접근을 통제하여, 임의로 다른 객체의 매모리에 접근하지 못하도록 하는가?
*First-class: 스케쥴링가능한 단위인가?
*Observability: 다른 객체(혹은 다른 보호 도메인)의 내부 상태를 쉽게 모니터링/검사하고, 필요 시 변경할 수 있는가? 많은 Isolation기법이 채택하고 있는 Default-deny모델은 X로 간주하였다.
*Transparent: 개발자가 이미 개발한 프로그램에 명시적으로 인지하고 제어해야 하는 추가적인  부분이 있는가?
*Fault recovery: 만약 한 객체의 작동이 잘못되었을 경우, 잘못되기 전으로 프로그램의 State를 복구 가능한가?