VEDA 54일차 - 리눅스 커널 프로그래밍

 

1. 배타적 접근(-> 공유된 리소스, 화장실) : 한 프로세스가 자원을 독점한다.

2. 순차적 접근(-> 공유된 리소스, 바통) : 프로세스 간 자원 접근 순서가 정해져 있다.

 

Race condition : 두 개 이상의 프로세스가 동일 자원에 접근하는 상황

Critical section : Race condition이 발생하는 해당 코드 영역

 

아래의 동기화 방식들은 동적 또는 정적으로 인스턴스 생성이 가능하다.

 

세마포어(Semaphore)(semaphore.h)

P 연산 - 획득(세마포어 값을 감소) => 실패 시 대기큐로

V 연산 - 반환(세마포어 값을 증가)

Binary : 세마포어가 1 개

Counting : 세마포어가 N 개

 

read/write 세마포어(linux rw_semaphore)

read 쪽이 write 쪽보다 우선 순위가 높다.(write를 하게 되면 데이터가 변경되니까, 우선은 read 쪽부터 처리해준다.)

read, write의 함수가 다르다.

 

뮤텍스(Mutex)(linux/mutex.h)

locked(0) / unlocked(1) : unlock 상태에서 사용이 가능하다. lock이 된 횟수만큼 unlock되어야 자원을 사용할 수 있다.(recursive)

 

컴플리션(Completion)

순차적인 방법을 구현하기 위한 방식

 

스핀락(Spin Lock)(linux/spinlock.h)

일반적인 상호 배제 도구들에서는 프로세스가 sleep 상태가 된다면, 스핀락은 작은 루프 상태로 들어가서 계속 락을 확인하며 루프를 스핀하면서 대기한다.

spinlock은 case에 따라서 사용법이 다르다.

 

Sequential Lock

Writer 쪽의 우선순위가 reader보다 높다.

 

블록킹 입출력

프로세스는 블록킹 -> 실행 큐에서 제거 -> 이벤트가 발생할 때까지(대부분이 인터럽트 서비스 루틴)

시그널: software oriented signal

인터럽트: hardware oriented signal

이벤트: hardware oriented, 인터럽트와는 다름, ex) timer -> (trigger) ADC

    이벤트라는 단어는 워낙 많이 쓰여서 문맥을 살필 필요가 있다.

블로킹 IO의 경우 write 보다는 read에서 일반적이다.

 

작업의 딜레이

CPU(x8), RAM(x4), fast device(x2), slow device(x1) 각 모듈 사이의 동작 속도가 다르다.

=> 별도의 조치가 없으면 사용자가 원하는 동작을 원하는 시간에 보장할 수 없다. 특히 CPU가 디바이스 동작을 완료하기 전까지 대기하는 경우 문제가 발생한다.

jiffies : 한 틱 당 소모되는 시간(seconds * HZ)

Hz : 해상도는 진동수와 동일한 비율로 증가한다 => 해상도가 높아지면 더 정밀하게 시스템 콜을 사용하거나, 자원 사용 현황, 측정값, 프로세스 선형성 등에 개선이 있다. 단 타이머 인터럽트 핸들러를 실행하는데 소비가 크다.

linux는 delay함수를 제공한다. => 제일 끝단에는 어셈블리 함수로 구성(정확하게 jiffies를 구할 수 있다.)

 

high resolution timer : nano 단위의 시간까지 측정, 단 너무 많은 타이머 인터럽트 발생 => 본 작업 수행에 문제 발생