🔹IoT

디바이스에 센서, 프로세싱 기능, 소프트웨어 및 다른 기술들을 합쳐 여러가지 서비스를 제공하는 것을 IoT라고 한다.

발전 과정

1. 센서의 값을 display
2. 무선 통신 기능을 사용해 센서들의 값을 모아 가치있는 데이터 얻음
3. 다양한 IT기술을 적용하며 데이터 처리 및 서비스 제공

이처럼 센서에 통신(connectivity)과 인터넷 기능을 붙이니까

• 긴 기간의 데이터 얻음
• 여러 센서의 데이터 얻음
• 여러 공간의 데이터 얻음
  → 많은 데이터를 처리(빅데이터, 인공지능 등)하며 의미있는 정보 얻음
  

IoT는 비쌈, 잘 고장남.. 사람 쓰는게 더 쌈

⭐ IoT 개발의 Requirement:

• 싼 하드웨어 및 시스템, 효율적인 소프트웨어
• 쉬운 설치 및 관리, 잘 안고장나게 → 오래가는 배터리 동작, 세팅 안해도 동작 잘 되도록, 오작동 시 스스로 복구

에너지 부분

• 적은 비용, 가벼운 하드웨어로 배터리 오래가게 하기 (최소 1년)
  • 기회를 보고 많이 자야 오래가게 할 수 있다!!
    → Sensing optimization, Wireless communication optimization
• 다양한 센서(노드)가 비슷하게 수명이 다하도록 하기
  
  

Sensing optimization

센서는 보통 특정 소자의 저항을 측정하여 데이터를 얻는다. 그래서 에너지가 많이 소비되는 작업이다. → 최적화 해서 필요한 부분만 센싱해야한다
에너지와 정확도의 tradeoff

고려해야 하는 것

• deadline: 센서 데이터가 제공되어야하는 기한 (빈도가 deadline보다 짧아야 함)
• age of information: 센서 데이터의 유효 기한 (안에 데이터가 전달되어야 함)

policy

• periodic sensing: 주기를 고정하여 센싱
• triggered sensing: 싼 간접 센서를 사용하여 센싱 유무 결정

Robust system design

• 강인해야한다. 쉽게 설치할 수 있고 관리가 적어야 한다.
  • plug and play: 큰 세팅 없이 동작이 잘 되도록
  • 오류가 안날만큼 간단하게 시스템 구축
  • 오류 발생 시 스스로 복구할 수 있는

🔹Process/Thread Management

🔸Process

• 프로그램은 instruction의 집합으로 저장소에 저장되어있음
  • 소스코드가 동일하면 같은 프로그램
• 프로세스는 loader에 의해 메모리에 올라간 프로그램
  • 소스코드가 같은 프로그램이 여러개 실행되면 각자 다른 프로세

memory layout

프로세스는 text, data, heap, stack 영역으로 구분되어있다

• Program counter: 다음에 어떤 instruction을 수행할 지 알려주는 register값 (CPU내에 존재)
  • 각 프로세스마다 PC를 가진다
• text section: program code(Instruction)
• Data section: global variable 보관(초기화 유무에 따라 구분되어 보관)
• Stack: 일시적인 데이터 보관 장소 (ex. function parameter, return address, local variable)
• Heap: 프로세스 실행 중에 동적으로 할당되는 메모리 (malloc, free)

메모리에 프로세스가 올라갈 때, Data section의 크기는 고정되어있고(Static memory), Stach과 Heap은 실행 중에 필요에 따라 동적으로 할당되고 해제된다(Dynamic memory)
위는 user space이고, kernel space까지 붙이면 아래와 같다. kernel space는 모든 프로세스가 공유하는 공간이다.

Process state

프로세스는 능동적 존재이기 때문에 실행되면서 상태가 변화한다. 프로세스가 생성되고 종료되는 과정에서 Running, waiting, ready 상태 변화가 반복된다.

^ State Transition Diagram

• New: 프로세스 생성 됨
• Ready: 프로세스가 실행 대기, processor(CPU)에 할당되기를 기다리는 중
• Running: Instruction 실행 중 (스케줄링되어 CPU를 할당받아 실질적으로 동작)
• Waiting: 프로세스가 event가 일어나기를 기다리는 중
• Terminated: 프로세스의 excution이 종료

ready는 일을 끝내고 스케줄러에 들어갈 준비 된거고, waiting은 일을 끝내고 I/O까지 기다리는 중

Process control block (PCB or TCB)

프로세스를 관리하기 위한 테이블로, 특정 프로세스와 연관된 여러 정보를 가지고 있는 자료구조

• Process State: new, ready, running, waiting, terminated
• Program Counter
• CPU Registers
• CPU scheduling information: 우선순위, 큐에 대한 포인터 등과 같은 scheduling 파라미터 포함
• Memory-management information
• Accounting information: CPU 사용 시간, open한 파일 정보
• IO status information

리눅스에서 task_struct라는 구조체에 PCB가 정의되어있다.
리눅스는 여러가지 프로세스를 linked list로 관리하는데, linked list의 포인터는 running중인 프로세스를 나타낸다. running 프로세스가 바뀌면 PCB의 값을 업데이트하며 포인터 값을 바꾼다.

Process scheduling

muli programming이나 multi tasking을 만족하기 위해 스케줄러는 다양한 알고리즘을 사용한다.
스케줄링에 따라 CPU에게 할당되는 프로세스를 바꾸게 된다 → context switching

Context Switch

CPU를 다른 프로세스로 swtich하기 위해서, 이전의 프로세스 상태를 보관하고 새로운 프로세스의 보관된 상태를 복구하는 작업

• ⭐ context: 지금까지 진행된 일의 문맥? 정보를 나타내는 값 (프로세스 상태, CPU register값, PC, 메모리 관리 정보 등 → 프로세스의 PCB에 표현 됨)
  • context를 파악하고 있어야 효율적으로 일을 할 수 있다. 제대로 전달되지 않으면 오류 또는 반복될 수 있기 떄문
• interrupt나 system call이 들어오면 과거 프로세스의 context를 PCB에 저장하고(context save), 실행할 프로세스의 PCB에서 saved context를 복구(context reload/resume)

Context overhead

• 과거 context를 저장하고, 실행할 context의 정보를 로드하는 과정에서 딜레이가 발생할 수 밖에 없다 → CPU가 노는 시간 발생(overhead)
• 예전엔 이 overhead가 좀 커서 이를 보완하기 위해 thread라는 개념이 나옴 → 최대한 공유하는 리소스를 늘리자
  
  

Operations on processes

지금까지는 프로세스 관리, 이제는 linux에서 어떻게 동작하는지
실행되는 동안 프로세스는 여러 개의 새로운 프로세스를 생성할 수 있다. 생성하는 프로세스를 Parent, 생성된 프로세스를 child라고 한다. child프로세스는 또 새롭게 다른 프로세스를 생성할 수 있으며, 그 결과 ‘프로세스의 트리’를 형성한다.

부모 프로세스에서 자식 프로세스를 만드는 2가지 방식
1. OS에서 새로운 프로세스에 대한 자원을 할당
2. 부모가 가진 자원 일부를 자식 프로세스에게 할당 → 보통 이거

fork()

• 나와 동일한 프로세스를 만드는 명령어 (copy)
• fork() 명령어가 나오는 줄부터 프로세스가 복제, 그 밑에부터 동시 수행
• pid를 return하므로, pid값만 다르다 → 보통 if문으로 구분해서 다른 동작을 할 수 있도록
  • parent pid=1, child pid=0

exec()

• 복제본이 아닌 다른 프로그램의 프로세스를 실행
• exec()명령어가 나오는 순간 다른 프로그램을 실행하므로 그 밑의 코드는 아예 실행 안됨

wait()

• 부모 프로세스가 자식 프로세스가 끝날 때까지 기다림
• 동기화, 선후관계 가능
• waitpid(): 특정 자식이 끝나는걸 기다릴 수 있음

system()

• fork-exec-wait를 통합한 system call
• fork해서 두 개의 동일한 프로세스가 생성되고, 하나는 exec에 의해 다른 프로그램을 실행한다. 그리고 부모 프로세스는 다른 프로그램을 실행하러간 자식 프로세스를 기다린다.
  
  

Process termication

프로세스가 실행을 끝내면, exit() system call을 사용하여 프로세스를 종료


부모 프로세스는 abort()로 자식 프로세스를 강제 종료할 수 있다.

• child가 자신에게 할당된 자원을 초과하여 사용하는 경우
• child에게 할당된 task가 더 이상 필요 없는 경우
  
  

정상적으로 종료하기 위해서는 꼭 부모는 자식이 종료되도록 기다려야한다. 그렇지 않으면 아래와 같은 문제가 발생할 수 있다.

• 좀비(Zombie) 프로세스: 자식은 끝났는데 부모가 wait()하지 않은 경우 → 자식의 자원은 해제됐지만 PCB상에는 남아있어 스케줄링 때 방해될 수 있다.
• 고아(Orphan) 프로세스: 자식이 살아있는데 부모가 먼저 종료된 경우(wait()를 못한 경우) → 자식을 끝내줄 부모가 없어 자원 관리에 문제가 발생할 수 있다.

이를 해결하기 위해 OS는 부모가 종료되면 자식도 종료되는 cascading termination 방식을 주로 사용한다. (폭포)

🔸Thread

text, data, heap은 전부 공유하고, stack만 따로 관리하여 thread간 switching을 할 때 stack만 스위칭할 수 있도록한다. → 좀 더 빠르고 효율적

clone()

• linux에서 thread를 만드는 system call
• clone과 fork는 거의 똑같은 동작을 한다..