생각하며, 꾸준하게

Barrier의 개념이나 구현을 완전히 자세하게 하진 않고, 간단하게 개념을 알아본 뒤, IPC 중 하나인 SIGNAL을 이용해서 간단하게 구현해보자. > Barrier란? 간단히 말해서 동기화 도구 중 하나이다. 같은 작업을 여러 processors가 나눠서 진행중이라면, 다른 놈들보다 먼저 본인의 일을 끝내는 processor가 나오기 마련이다. 그럴때 같은 일을 하는 다른 모든 processors가 일을 끝마칠때까지 기다리도록 하는 것이 barrier이다. 위 예시처럼 특정 작업이 끝나고 다른 작업을 시작해야할때 적용할 수 있다. SIGNAL을 이용해서 이런 기능을 하도록 하려면 어떻게 해야할까? 0. 일단 모든 processors는 미리 정해둔 SIGNAL을 받아서 카운트를 하도록 signal h..

앞서 배운 pipe/named pipe나 signal도 process간 통신 수단 중 하나이다. 이 글에선 다른 IPC 관련 명령어/함수들을 알아본다. 여기선 아래 두가지 IPC 수단을 추가로 배운다. 1. mesasge queue를 이용한 IPC 2. shared memory를 이용한 IPC 이외에도 file lock, semaphore, socket, 일반 file 등등.. IPC 관련 개념/system calls가 많긴한데 여기선 위 두가지만 배운다. (pipe도 결국 위 두 개념에 속하는게 아닌가? → 말만 보면 그런 것 같긴한데, UNIX/LINUX에서 위 두가지를 전문적으로 해주는 기능이 존재함. pipe도 IPC는 맞지. pipe/message queue/shared memory 다 따로따로..

앞서 과정까지 우리는 분석을 위해 requirements를 기반으로 여러 Analysis 모델을 iterative/incremental하게 만들었다. 분석에서 business needs를 정했다면, 디자인에선 어떻게 system을 만들지에 집중한다. 분석 과정을 통해 우리가 만들/보완할 system이 어떤 기능을 어떤 흐름으로 해야하는지, 내부구조가 어떻게 되는지, 각 class/object들이 어떻게 상호작용하는지를 알았다면,, 이제는 구현으로 넘어갈 수 있도록 Analysis 모델을 Design 모델로 발전시켜나가야한다. (특히 Class D를...) 이 글에선 그런 Design 과정의 전체적인 흐름을 보도록 하겠다. Design 과정의 특징은 다음과 같다. 1. 구현을 위한 청사진을 제공한다. 2...

pipe는 UNIX system IPC(InterProcessCommunication) 중 하나이다. 즉, Process간 통신을 할때 사용된다. > File Descriptor file descriptor란 process가 file을 다루기위해 사용하는 개념으로 0 이상의 정수값을 갖는다. processor가 생길때마다 각 processes는 각자 file descriptors (목록)을 가진다. process는 file에 직접 접근하는게아니라 이 file descriptor을 통해서 지정된 file에 접근한다. 그럼 이제 processor가 file을 open할때마다 사용하지 않는 file descriptor 숫자 중 "가장 작은 값"과 해당 file을 연결(?)해서 접근할 수 있게 해주는 것이다. ..

아래 사항들을 배운다. 1. Implementation of subset of core instructions 2. ISA가 구현에 끼치는 영향 3. 구현 방식에 따라 CPI나 clock rate에 끼치는 영향 (여기서 배우는 기본 개념들은 서버부터 임베디드 processor까지 모든 컴퓨터에 적용된다.) > Overview of Implementation 모든 instructions은 아래 두가지 공통 사항들을 출발점으로 진행된다. 1. PC에 저장된 주소가 가리키는 곳에 저장된 instruction을 memory에 올린다. 2. 양식에 맞게 register 1개 혹은 2개의 값을 읽어온다. 이후 진행 과정은 instructions 종류에 따라 다르게 진행된다. 하지만 RISC-V의 simplicity..

Shell이 무엇인지 알아보고, Shell의 작동 원리를 카피해 비슷한 기능을 하도록 간단하게 구현하는 방법을 알아본다. 그 전에 기본이 되는 개념인 program과 process의 차이에 대해서도 간단하게 알아본다. Program : disk에 file로 저장된 machine instructions Process : memory에 올라와있는 machine instructions, CPU가 각 줄을 실행한다. (PCB라는 구조체가 현재 프로세스 정보를 담고 관리한다) file system이 disk의 file 정보들을 포함/관리 하듯이, User Space라는 것이 memory의 processes와 그 data 정보를 포함한다. 메모리는 사실 아래 그림과 같이 kernel space와 user space..

`who` 명령어는 누가 현재 접속 중인지를 출력한다. 이걸 차근차근 구현해보자. (중간중간 유용한 정보 많음) 우선 who 명령어가 어떤 명령어인지 알아보려면, `man who` 명령어를 통해 who의 manual page를 볼 수 있다. 읽다보면 who 명령어가 `/var/run/utmp` 파일을 사용해 정보를 읽어와 출력한다는 것을 알 수 있다.(구체 경로는 아마 환경따라 다를거임) 교수님께서 알려주셨는데, 보통 `/var`에 시스템 로그 관련 파일들이 있다. utmp가 이젠 궁금하니, `man utmp` 명령어를 통해 utmp의 manual page를 보자. 참고로 utmp라는 keyword가 나오는 모든 manual page를 검색하고 싶다면, `man -k utmp` 명령어를 이용하면 된다. ..

Linux File Systems는 files과 directories의 collection이다. 우선 directory든 file이든 모두 Hard Disk에 저장된다. Hard disk는 Sector라는 기본 unit으로 나뉘어진다. 우리는 각 Sector에 번호를 부여함으로써 마치 하드디스크를 마치 큰 배열처럼 사용할 수 있고, 그런 점을 이용해 Linux의 파일 시스템은 아래와 같은 Layout을 띄게 된다. 1) The Supuer Block : File system 자체의 구조에 대한 정보를 담고 있다. ex. 각 area의 크기, 사용되지않는 data blocks의 위치 등등 2) The Inode Table : `struct inode`에 각 file의 정보(data 위치, size, Use..

이 카테고리의 이 글 바로 직전에 썼던 글에 잘못된 정보가 꽤 있었다. 당시에 수업을 두번정도만 듣고 나름 찾아보며 정리했던 글이라 그랬다. 내 개인적인 생각도 많이 들어갔었고, 애초에 잘못된 정보도 있었고... 그래서 어느 정도 배우고 중간고사가 지난 지금 다시 한번 정리해볼까한다. (기존 글은 필요한 내용과 핵심 내용만 여기로 가져오고 원본은 삭제함) 배경 우리가 아는 Java 같은 고수준 PL의 아래엔 무엇이 있을까? 무엇을 기반으로 했기에 그런 언어를 이용한 설계가 기능할 수 있는걸까? 갑자기 하늘에서 떨어진건 아닐 것이다. 그 기반을 살펴보기 위해 물리학까지 내려가자면 끝도 없을 것이고,, 납득할만한 수준에서 보자면 그 시작은 트렌지스터이다. 트렌지스터 없이 회로의 한 지점에서 다른 지점까지 정..

(교수님께서 챕터5를 보고 챕터4를 하자고 하셔서 그 순서로 정리) programmers는 용량 제한없는 빠른 메모리를 원한다. 이 챕터를 통해 그 환상을 최대한 실현하는 법을 알아본다. 물론 계속 큰 메모리를 계속 빠르게 접근하는 것은 불가능하다. 자 그럼 그 기저에 깔린 원리를 알아보자. > Principle of locality 1. Temporal locality (locality in time) : 특정 item이 한번 referenced되면, 해당 item은 짧은 시간 내에 다시 referenced 된다는 것 2. Spatial locality (locality in space) : 특정 item이 한번 referenced되면, 해당 item의 주변 item들이 짧은 시간 내에 다시 refer..