Interrupt
- ECF(Exceptional Control Flow)의 종류 중 하나
- ECF에는 인터럽트(Interrupt), 트랩(Trap), 오류(Fault), 중단(Abort)가 있다.
- 인터럽트는 ECF중 유일하게 비동기
- 인터럽트 PIN이 High가 되면 발생
- 인터럽트 벡터 테이블(IVT)을 참조하여, 해당 인터럽트에 맞는 인터럽트 핸들러를 호출한다.
- 스케쥴링(Scheduling)을 하기 위해서는, 일정주기(약 10ms)로 발생하는 인터럽트가 필요함. (타이머 인터럽트)
- 실제로 타이머 칩이 존재하며, 미리 설정한 간격으로 하드웨어 신호를 발생한다.
- Pintos에서는 8254 timer
Time Sharing
- CPU가 하나만 있더라도 여러개의 CPU인 것처럼 작동함
- 시분할 방식(Time Sharing)을 통해 달성할 수 있음
- 프로세스 개별로 봤을때는 느려지지만, 여러개의 프로세스가 동시에 실행되고 있는 것처럼 보임
- Temporal Virtualization
- 어떤 프로세스에게 얼마나 CPU를 사용하게할지는 스케쥴링 정책(Scheduling Policy)를 통해 관리함
- 스케쥴링 정책은 공평성과 성능이 고려되어야한다.
Synchronization
- multithread 프로그래밍에서는 공유자원을 동시에 접근할 때 원자성이 보장되지 않는다면 여러 문제가 생긴다.
- 원자성을 보장하기 위해 Lock을 사용한다.
- 이번 프로젝트에서는 Semaphore를 사용함.
- 이진세마포어: 초깃값이 1인 세마포어
- 임계영역에 한개의 thread만 진입가능.
- 방 안에 들어갈때, 열쇠가 한개만 있는 경우
- 한번에 한 사람만 들어갈 수 있다.
- 방 안이 임계영역
Primitive
- 컴퓨터 처리의 가장 기본단위로 정의된 것 (출처: 위키백과)
- 원자성을 가진다.
- 동기화 프리미티브: 세마포어, 조건 변수 등...
C의 매크로를 통한 자료구조 확장
평소에도 자료구조를 배우면서 들었던 의문이 있다. 다양한 type에 대응하는 자료구조를 최대한 코드 변경없이 대응하는 방법이 있는지 궁금했었다.
간단히 Singly Linked List를 예로 들자면, 그동안 예제로 배웠던 Singly Linked List의 node 구조체는 member 변수로 1) 다음 node를 가리키는 포인터 변수 와 2) 값으로 가질 int | char | float ... 등 자료구조에 담을 변수 가 있다. 하지만 char에 대한 linked list로는 char이외의 type에 대응할 수 없다.
pintos의 list.c 에서는 다른 방식으로 대응하는데,
1)
struct node구조체에 key는 멤버변수로 가지지 않고, 다음 node의 주소를 가리키는 포인터만을 멤버변수로 가진다.
2)struct node를 link하여 linked list를 만든다.
3) 그리고 사용할 구조체struct some에 그 node를 포함(embed)한다.
4) linked list의 node 만으로 자료구조의 조작이 이루어진다.
5)struct some이 필요한 경우 C의 매크로를 통해 확장한다.
node에는 그 어떤 key도 없기때문에, 매크로로 확장하기만 한다면 모든 type의 Singly Linked List를 만들 수 있다.
나중에 C++의 STL을 뜯어볼 계획인데, 같은 방식으로 구현되어 있을지 궁금하다.
clang formatter
- 개발자마다 코딩 스타일이 다르다.
- 팀에서는 일관된 코딩스타일을 유지할 필요가 있다.
- vscode에는
format on save기능이 있어, 저장할 때마다 포맷팅 할 수 있다. - clang formatter는 설정 파일로
.clang-formatter파일을 사용한다. - javascript 프로젝트에서는 같은 역할을 하는 prettier가 있다.
git 전략
- git을 협업도구로 사용하면, branch가 꼬이는 경우가 있을 수 있다.
- 그래서, branch를 관리할 전략이 필요함
- 처음에는 git flow전략을 생각했었다.
- 프로젝트를 체계적으로 관리할 수 있는 장점이 있지만, 그만큼 브랜치가 많기때문에 다소 복잡할 수 있다.
- github에서 사용하기 편한 github flow 전략을 채택하였다.
- main 브랜치에서 새 branch를 만들고, PR 생성 후, merge하는 방식
- 주간시험에서 답안을 제출하던 방식과 동일했기 때문에 바로 적응함
