Processes and Threads

preemptive scheduling: HW에 의해 cpu를 뺏기는 scheduling이다.
non-preemptive scheduling: SW에 의해 interrupt가 발생한다. I/O가 오래 걸릴 것 같으면 voluntarily yield한다.

새로운 process가 생기면 os가 그 process의 content를 build한다.
Unix는 부팅 시 0번 프로세스만 생성하고 그 이후는 fork한다.
프로세스 생성할 때는 실행 파일이 os에 전달되고 os가 그 exe를 메모리의 code segment에 로드함으로써 생성한다.
fork가 불리면 그 부른 parent를 stop시키고 context(프로세스가 갖고 있는 자원)를 복사해서 pid만 바꾸고 나머지는 똑같은 child process를 만든다.
fork 뒤에는 exec이라는 system call이 필요하고 exec이 끝나면 exit을 불러서 parent를 깨운다.
Zombie state: exit하고 exit state를 남기고 parent가 그 state를 보기 기다리는 상태이다.

CPU      --->       MMU(Memory Management Unit)       --->       physical memory
      (logical addr.)                                                     (physical addr.)

각 process는 독자적인 address space를 갖는다.
각각 0 ~ 2^(32) -1의 address를 갖지만 각 프로세스의 100번지는 서로 다를 것이다.
proc 0과 proc 1이 소통을 하기 위해서는 file을 사용한다.

-----------------------------------------------------------------------------
server에서 request를 날릴 때 request queue가 있어서 일정 주기마다 request queue에 처리할 것이 있으면 처리한다.

iterative server: 서버가 직접 처리한다. 단순하다.
concurrent server: 처리할 worker process를 fork한다. 그동안 server process는 다른 request를 빼와서 또 fork함으로써 response time이 줄어든다.
Thread도 ready, running, wait state가 있다.
Thread는 stack으로 구현된다. thread = instruction seg = seg of func = stack
multi-threading하면 하나의 process가 여러 stack을 갖게 된다.
user mode일 때는 user stack을 쓰고 kernel mode일 때는 kernel stack을 쓴다.

User-level thread: interrupt를 thread 단위로 forward 시켜주지 못하기 때문에 preemptive scheduling을 할 수 없지만 장점으로는 OS를 고치지 않고도 multi-threading을 할 수 있다. 수행 중 input이 없어 reactive하지 않은 scientific programming에 유용하게 쓰일 수 있다.
Kernel-level thread: thread 생성과 종료를 os가 한다.interrupt forwarding은 가능하지만 extra overhead가 발생한다.
Combined thread: 대부분 user-level thread로 구현이 되지만 interrupt가 왔을 땐 thread로 forwarding함으로써 preemptive가 가능해진다.



댓글

댓글 쓰기

이 블로그의 인기 게시물

논문 정리 - MapReduce: Simplified Data Processing on Large Clusters

Abstract 맵리듀스는 큰 데이터 셋을 다루는 프로그래밍 모델이다 . 사용자는 map 함수를 통해서 키 / 밸류 쌍을 이용하여 intermediate key/value pair 를 만들고 reduce 함수를 통해서 그 intermediate pair 들을 같은 key 별로 합쳐준다 . 많은 일들이 이런 모델을 통해 표현될 수 있다 . 이 모델은 분산 시스템이나 병렬 시스템에 대한 경험이 부족하더라도 분산 시스템의 자원을 쉽게 사용할 수 있게 해준다 . 1. introduction 데이터가 많아지면서 reasonable time 안에 작업을 끝내기 위해 수백 혹은 수천대의 기계에 분산되어야 했다 . 이 때 어떻게 연산을 병렬화하고 , 데이터를 분산하고 , 실패 작업을 어떻게 처리할지가 이슈가 되었다 . 이런 복잡한 문제들을 해결하기 위해 병렬화의 세세한 부분들은 숨기고 fault tolerance 하며 데이터를 분산시켜주고 로드 밸런싱을 해주는 라이브러리를 통해서 연산을 맵과 리듀스로 간단히 표현하도록 했다 . 2. Programming Model 사용자가 직접 만드는 맵 함수는 입력으로 key/value pairs 를 받아서 intermediate key/value pairs 를 만든다 . 그러면 intermediate key/value pairs 에 대해서 맵리듀스 라이브러리가 같은 key 별로 value 들을 묶어서 리듀스 함수로 보내준다 . 마찬가지로 사용자가 직접 만드는 리듀스 함수는 이 데이터를 받아서 key 별로 묶인 value 들을 합쳐서 표현한다 . 리듀스 함수에 전달되는 intermediate 데이터는 iterator 의 형태로 전달되기 때문에 메모리에 다 안 들어갈 정도로 큰 데이터도 처리할 수 있다 . 예를 들어서 , 어떤 문서에 있는 각 단어들이 몇 번 나왔는지 세는 프로그램을 생각해보자 . 그렇다면 맵 함수는 입력으로 < 문서 이름 , 문서 내용 > 의...
자세한 내용 보기

논문 정리 - The Google File System

The Google File System 1. Introduction 새로운 관점 component failure 은 예외가 아니라 일반적인 상황이다 . 그래서 constant monitoring, error detection, fault tolerance, automatic recovery 가 필요하다 . 파일의 크기가 커졌다 . I/O 작업이나 block 크기 등이 고려되어야 한다 . 원래 있는 데이터에 덮어쓰는 작업보다는 새로운 데이터를 추가한다 . 따라서 appending 이 성능 최적화에 중요해졌다 . 2. Design Overview 2.1 assumptions 시스템은 잘 고장나는 저렴한 장비들로 구성되어 있다 . 시스템은 큰 파일이 있다 . 작은 파일들도 있지만 optimizing 할 때는 고려하지 않는다 . 로드는 주로 큰 스트리밍 읽기와 작은 랜덤 읽기로 구성되어 있다 . 로드는 또한 파일에 데이터를 추가하는 많은 sequential write 가 있다 . 같은 파일에 여러 사용자가 동시에 데이터를 추가하는 경우도 잘 고려해야 한다 . 빠른 반응 속도 보다는 high sustained bandwidth 가 더 중요하다 . 대부분의 타겟 애플리케이션은 데이터 뭉텅이를 빠른 시간 내에 처리하는 것을 중요하게 여긴다 . 2.2 Interface 파일은 hierarchically , 디렉토리에 정렬돼있고 path name 으로 구분된다 . 또한 GFS 는 snapshot 과 record append 기능이 있다 . snapshot 은 파일이나 디렉토리 트리를 복사한다 . record append 는 다수 클라이언트가 데이터를 하나의 파일에 동시에 추가할 수 있도록 해준다 . 각 append 의 atomicity 를 보장하면서 . 2.3 Architecture 하나의 마스터와 여러개의 chunkserver 로 구성되어 있다 . 그리고 다수의...
자세한 내용 보기

kazoo: Using zookeeper api with python

``` pip3 install kazoo ``` https://kazoo.readthedocs.io/en/latest/basic_usage.html https://kazoo.readthedocs.io/en/latest/api/client.html ### 접속 ``` from kazoo.client import KazooClient zk = KazooClient(hosts='127.0.0.1:2181') zk.start() ``` 호스트에 접속할 때 default port는 2181이다. ### 상태 Listener zookeeper의 상태가 변하는 것을 알 수 있다. ``` from kazoo.client import KazooState def my_listener(state):     if state == KazooState.LOST:         # Register somewhere that the session was lost     elif state == KazooState.SUSPENDED:         # Handle being disconnected from Zookeeper     else:         # Handle being connected/reconnected to Zookeeper zk.add_listener(my_listener) ``` LOST CONNECTED SUSPENDED 의 state를 가질 수 있다. 가능한 상태 변화 - LOST -> CONNECTED - CONNECTED -> SUSPENDED - CONNECTED -> LOST - SUSPENDED -> LOST - SUSPENDED -> CONNECTED ### CRUD - `zk.create("/my/favorite/node", b"a value")` `create(path...
자세한 내용 보기