eeminsu's Devlog

[F-Lab] Java 백엔드 코스 3개월 솔직후기

eeminsu — Wed, 25 Jun 2025 21:48:11 +0900

현재까지 진행한 내용

멘토링도 어느새 13주차까지 진행하였다. 멘토링을 시작한게 엊그제 같은데 벌써 한달여밖에 남지 않았다..

1개월차에는 자바에 대한 이론 공부를 깊게한 이후 2개월차부터 스프링에 대한 학습과 프로젝트 기획을 병행하였다.

원래라면 지금은 프로젝트의 기능을 대부분 구현하고 리팩토링을 하면서 멘토님의 코드리뷰를 받아야하는 단계이지만

지난달 초에 지원했던 회사들이 운좋게 모두 서류합격이 되면서 면접준비와 프로젝트를 병행하게 되었다.

사실 병행이라기보다 면접 준비에 더 집중하게 되었는데, 이 부분은 멘토님께서 먼저 프로젝트보다 면접 준비에 무게를 두자고 하셨다.

그렇게 멘토님께서 이력서와 경력기술서를 토대로 예상 면접 질문을 뽑아주셨고 모의 면접식으로 멘토링을 진행하였다.

사실 이전에도 멘토링 자체가 본인이 학습한 내용에 대해서 질문과 답변을 이어가는 방식이어서 어느 정도 기술 면접에 대비를 할 수 있었다.

특히 한 기업의 기술면접에서 자바에 관해 꼬리질문을 이어가며 깊게 물어보았는데 멘토링때 학습한게 매우 도움이 되었다.

그렇게 기술면접에서 합격을 하게되었다.

컬쳐핏 면접에 대해서도 멘토님께서 본인의 경험을 바탕으로 예상 질문들을 말씀해주시면서 모의 면접을 해주셨다.

덕분에 모든 채용과정을 마치고 최종합격을 하게되었다.

프로젝트를 진행하며

프로젝트를 진행하면서 얻고자 했던 부분은 코드리뷰 경험과 사용해보지 못한 기술 스택 경험이었다.

멘토님의 코드리뷰를 받으면서 현재 내 잘못된 코드 스타일을 개선해보고 싶었고,

사용해보지 못한 기술 스택을 적용하면서 왜 이런 기술을 사용하는지에 대해서도 제대로 알고 싶었다.

그러나 상기의 기술한 바와 같이 취업 활동을 병행하고 운좋게 계속해서 채용과정이 진행되면서 프로젝트를 진행하지 못하였다.

이 부분은 살짝 아쉬웠다...

멘토링을 진행하며

멘토링을 통해서 얻을 수 있는 부분은 개인마다 다르고, 여러가지가 있겠지만

개인적으로는 멘탈적으로 안정감을 찾을 수 있어서 굉장히 좋았다.

길을 헤매고 있을 때 방향을 알려주고, 쓸데없는 고민과 걱정을 하고 있을 때 해당 부분을 해소해주는 것이 나에게 있어 매우 도움이 되었다.

특히 면접 준비를 하면서 정말 걱정도 많고 방황할 때마다 멘토님께 고민을 말씀드리면 현실적인 조언과 응원을 해주셔서 잘 이겨낼 수 있었던 것 같다.

앞으로 남은 멘토링은 회사를 다니면서 진행을 할 것 같다.

운좋게도 멘토님과 같은 도메인에 취업을 하게 되서 더 많은 도움을 받을 수 있을 것 같아 기대된다 ㅎㅎ

[F-Lab] Java 백엔드 코스 2개월 솔직후기

eeminsu — Mon, 19 May 2025 11:48:01 +0900

현재까지 진행한 내용

현재 8주차까지 멘토링을 진행했다.

어느새 전체 멘토링 기간에 반환점을 돌게 되었다..

1개월 간 이론 위주 학습이 끝나고 프로젝트를 진행하고 있다.

물론 프로젝트 진행 중에도 이론 학습은 병행해야 한다...ㅎㅎ

이론 학습은 Java, Spring까지 진행된 상태다.

이론 학습은 하면서 느끼지만 끝이 없는 기분...

서류 합격이 2곳이 되어 과제 진행과 면접 준비를 병행하다보니

프로젝트 진행은 더딘 상황이다..

멘토님께서 과제 코드 리뷰와 면접 준비를 같이 해주셔서 이 부분은 참 좋았다.

멘토링을 하면서 깨달은 점

멘토님께 채용 과제 코드리뷰를 받으면서 제일 많이 느꼈던 것은 "아 이거 알고있던건데" 였다.

이력서를 쓸데도 마찬가지였다. 분명 다 알고 있던건데 지켜지지 않은 것들이 많았다.

혼자 준비했더라면 발견하지 못했을 거다.

이력서 또한 여러가지 레퍼런스를 제공해주셔서 많은 도움이 되었다.

이력서 기반으로 면접 진행시 나올만한 질문들에 대해서 실시간으로 던져주셨다.

질문을 받으면서 느꼈던 점은 구현 당시에 내가 얼마나 문제 해결에 있어 깊게 생각을 안했는지에 대해 알 수 있었다.

멘토님께서 이런 부분에 대해서 추가로 발생할 수 있는 문제 상황과 해결법에 대해서 설명해주셔서 학습도 하며 면접 대비를 할 수 있었다.

정말 이럴 때 멘토링이 큰 도움이 된다고 생각한다.

프로젝트를 진행하며

프로젝트를 시작할 시기에 운이 좋게 두곳에서 서류 합격이 되었다.

동시에 채용 과정을 진행하고 있어서 프로젝트를 제대로 진행하지 못하고 있다...

프로젝트 주제를 선정할 때부터 무엇을 할지 고민이 많았다.

단순히 클론코딩처럼 특정 서비스를 만들기엔 시간이 부족하다고 느꼈다.

그래서 나는 기존 내 경력에서 부족한 부분이나 써보지 못한 기술 스택을 써보기로 하였다.

멘토링을 하면서 제일 기대가 됐던 부분이 멘토님의 코드리뷰였다.

이론 공부와 다르게 코드의 구조는 정답이 없어 어떤 방향으로 코드를 구현해 나가는 것이 좋은 방향인지 스스로 고민이 많은 상태였다.

이 부분을 현업 시니어 개발자에게 1:1로 코드 리뷰를 받으면서 배워갈 수 있다는 것이 너무 기대되었다.

우선 면접 준비 때문에 프로젝트의 뼈대만 구현해서 PR을 올렸다.

귀신같이 쌓이는 멘토님의 피드백..ㅎㅎ

이런식으로 리뷰를 받을 수 있어서 내가 놓쳤거나 몰랐던 부분에 대해서 알아갈 수 있어 좋았다.

마치며

2개월이란 시간이 너무 빨리 지나갔다.

2개월 사이에 기본기를 단단히 다질 수 있었던 것 같다.

그리고 공부, 이력서, 면접 등등 여러가지 궁금한 점에 대해서 멘토님의 피드백을 받을 수 있어서 좋았다.

앞으로 남은 2개월 동안 더 많은 것을 얻어갈 수 있도록 노력해야겠다..ㅎㅎ

[F-Lab] Java 백엔드 코스 1개월 솔직후기

eeminsu — Mon, 21 Apr 2025 10:59:45 +0900

왜 F-Lab인가

내가 잘하는 줄 알았다.

펌웨어 개발자로 커리어를 시작했다.

전자과를 졸업한 나는 전공 지식이란건 아무것도 없었다.

사수도 없었다. 그저 열심히 하는 것 밖에 몰랐다.

이런 저런 일도 많았지만 잘한다는 소리를 주변 동료, 상사에게 들었다.

그러던 중 직무와 다른 업무들이 쏟아졌고 챗바퀴 같은 업무에 지친 나는 백엔드에 흥미가 생기기 시작했다.

혼자서 독학을 하면서 업무를 병행했다. 체력적인 한계가 왔다. 업무하는 시간이 아까웠다.

공부 시간을 확보하기 위해 백엔드 전향을 결심하며 퇴사를 했다.

그러던 중 영업팀 차장님을 통해서 협력사에서 제의가 들어왔다.

굳이 공백을 가져가며 공부하지 말고 일을 하면서 배우는게 어떻겠냐는 차장님의 권유였다.

백엔드 경력이 없는 나를 왜 뽑으려고 할까라는 의심과 함께 폐를 끼칠 것만 같아 거절하였으나 협력사의 삼고초려 끝에 입사를 결심했다.

입사를 하고도 제법 일을 잘했다.

1년도 되지 않아 프로젝트의 백엔드 개발을 혼자서 맡으며 성공적으로 마무리했다.

큰 장애도 발생하지 않았다.

여느 스타트업과 마찬가지로 자금이 넉넉치 않아 자체 서비스 개발보다도 외주 개발을 위주로 흘러갔다.

회사에서는 빠른 구현을 원했다.

다른건 몰라도 빠르게 구현하는 것은 자신 있었다.

나는 이게 실력인줄 알았다.

겠냐?

이직을 고민하던 중 중 퇴사하신 분을 통해 연락이 왔다.

팀에서 백엔드 개발자를 충원하려고 하는데 관심이 있냐는 것이었다.

그렇게 면접 제안을 받고 부랴부랴 면접 준비를 했다.

예상 질문들에 대한 답을 준비하고 프로젝트를 진행했던 것들을 복기했다.

면접장에 들어섰다.

"객체지향이란 뭘까요?"

"JPA에서 N+1 문제가 발생했을 때는 어떻게 해결하죠?"

꼬리 질문도 이어지고 모르는 질문도 나왔지만 스스로 면접을 잘봤다고 생각했다.

결과가 나오기 전까지 연봉 협상할 생각만 했던거 같다.

다음날 불합격이라는 연락을 받았다.

어..? 왜지..?

그제서야 면접을 복기해봤다.

대답을 잘한줄 알았는데 엉뚱한 얘기를 잘도 떠들어 댄것이었다.

너무 쪽팔렸다.

내가 그동안 잘하는 줄만 알았다.

그러나 실상은 기본기도 없는, 구현만 할 줄 아는 코더에 불과했다.

기본기의 중요성을 깨닫게 되었다.

그래서 왜 F-Lab?

회사 사정이 어려워지고 결국 모종의 이유로 퇴사를 하게 되었다.

서비스 회사로 이직을 꿈꾸며 이력서를 넣었지만 모두 서류 탈락을 하게 되었고

마음은 더욱 조급해지며 공부 방향성은 계속해서 흔들렸다.

그러던 중 인프런 멘토링을 받게 되었다.

마음이 편안해지고 도움이 많이 되었다.

아 이런 멘토링을 주기적으로 받으면 좋겠다는 생각이 들었고 F-Lab을 알게 되었다.

후기도 정말 많이 찾아보고 F-Lab을 진행중인 멘티에게 상담도 받았다.

모두 공통적으로 언급되는 키워드는 기본기, 딥다이브, 개발자 마인드였다.

나에게 가장 부족한 것들이었다.

또한 다른 업체들 처럼 1티어 서비스 기업의 입사를 보장해주는 듯한 멘트없이

솔직하게 언급하는 점이 좋았다.

그렇게 F-Lab 멘토링을 시작하게 되었다.

멘토

F-Lab은 1:1로 멘토링이 진행되는 만큼 어떤 멘토를 만나느냐가 중요했다.

위에서도 언급했지만 정말 많은 후기글을 봤다.

블로그글부터 시작해서 디시까지..

멘토와 성향이 맞지 않아 환불받았다는 글도 많이 보여 제일 걱정된 부분이었다.

그러나 F-Lab은 멘토 변경이 가능하다.

멘토를 선정하는 과정에서도 멘티의 성향을 제출해서 여러 멘토를 선택할 수 있게 리스트업을 해준다.

리스트에서도 선택하고픈 멘토가 없다면 별도로 상담을 통해 멘토를 정할 수 있었다.

나 또한 멘토님을 추천받아 선택하게 되었다.

후기글에서 대부분 책, 인강을 구매해서 이론 학습을 진행하고

멘토님을 통해 많은 기술 질문을 받아 멘티의 답변에 대해 피드백을 주는 식으로 진행되는 것을 많이 봐왔는데

당연하겠지만 이 부분은 멘토님별로 진행 방식이 다른 것 같다.

멘토님께 받은 슬랙 메세지

나는 현재 이론 학습에 대해서는 자유도를 부여받고 기술 질문 또한 페이스에 따라 맞춰주시고 있다.

또한 멘탈적으로도 도움되는 말도 많이 해주신다.

당연히 공부 외적으로 이직, 진로, 이력서 첨삭 등등 모든 질문이 가능하고, 멘토님도 정성스럽게 답변해주신다.

단순히 커리큘럼대로 과외를 해주는 선생이 아니라 같은 업계에 있는 선배, 말그대로 멘토라는 느낌을 많이 받는다.

이런 피드백을 받는 재미도 쏠쏠하다..ㅎㅎ

1개월 동안 배운 것

멘토링은 한주동안 이론을 학습하고 해당 내용에 대해서 기술 질문을 받는 형식으로 진행된다.

첫 1개월은 자바를 학습하게 된다.

멘토님이 키워드를 몇가지 던져주시고, 꼭 학습해야할 부분에 대해서 말씀해주시면

해당 주차에는 말씀주신 내용을 학습하고 그 다음 멘토링에서 기술 질문을 받게된다.

답변에 대해 피드백을 해주시고 부족한 부분에 대해서는 설명을 해주신다.

JVM 메모리 구조부터 시작해서 객체지향이란 무엇인지, 인터페이스와 추상클래스의 차이는 무엇인지 등등

현업에서는 그냥 그런가 보다 하고 지나간 부분에 대해서 깊이 학습할 수 있었다.

위에서 서술했듯이 멘토님은 과외선생님이 아니다.(단순 강의를 해주는 사람이 아니라는 것이다.)

내가 한주동안 공부한 부분에 대해서 얼마나 깊이 공부했는지, 옳은 방향으로 공부를 했는지 체크해주신다.

그렇기 때문에 정말 깊이 학습할 수 밖에 없다.

단순히 회사를 다니며 혼자 독학을 했을 때와 비교해서 머릿속에 많이 남게되고 산재된 지식들이 연결되는 느낌이었다.

물론 학습 자체는 스스로 하지만 매주 멘토님이 방향을 알려주고 공부한 부분을 체크해주는 것이 많은 도움이 된다.

앞으로의 각오

이제 차주부터는 슬슬 프로젝트를 시작하게 된다.

프로젝트를 시작한다고 해서 이론 학습을 멈추는 것은 아니다.

스스로 지금까지는 공부 습관을 들이는 단계라고 생각하고 있다.

프로젝트를 시작하더라도 최소한 지금 공부하는 양과 시간, 깊이 있게 학습하기는 유지하는 게 목표다.

코딩테스트도 최소한 2시간씩 공부시간을 가져가고 있다.

이 부분도 계속 유지하는 것이 목표다.

[Java] Java에서 Hash를 많이 사용하는 이유

eeminsu — Wed, 9 Apr 2025 16:33:51 +0900

Hash

임의의 크기를 가지는 데이터(문자, 파일 등)를 해시 함수에 입력하게 되면 고정된 크기의 데이터를 출력하게 되는데 이를 Hash(또는 해시값, 해시코드)라고 한다.

해시 함수는 알고리즘을 이용해서 입력받은 키 값으로 키 값의 크기와 상관없이 해시를 만들어 준다.

해시 함수는 같은 입력값에 대해서 같은 출력값을 보장한다.

(입력값에 대한 무결성을 보장한다고 한다.)

해시 값을 이용해서 키 값을 찾는 것은 불가능하여 일방향성을 갖는다고 얘기한다.

Hash Table

해시 테이블은 이러한 해시 함수를 이용해 키에 대한 해시 코드를 반환받아 해시 코드를 통해 배열(bucket)의 인덱스로 환산해서 데이터의 접근하는 방식의 자료구조이다.

(Java에서는 HashTable, HashMap등을 통해 해당 자료구조를 사용할 수 있다.)

해시 테이블의 필수 조건은 고정된 크기의 배열을 선언하는 것이다.

일반적으로 테이블의 크기와 상관없이 키를 통해 상수 시간으로 빠르게 데이터에 접근이 가능하다.

인덱스는 해시 코드와 배열의 크기를 나머지 연산을 하여 환산한다.

HashCode % 배열의 크기

환산한 인덱스를 통해 배열에 데이터를 저장하게 된다.

해시 충돌 (Hash Collision)

나머지 연산을 통해 인덱스를 환산할 때 서로 다른 키더라도 같은 인덱스를 환산하는 경우가 발생한다.

이를 해시 충돌이라고 한다.

해시 충돌은 2가지 경우에 해당한다.

1. 서로 다른 키가 같은 해시 코드를 반환한다.
2. 키와 해시 코드가 서로 다르지만 같은 인덱스를 환산한다.

이와 같은 해시 충돌에 대한 해결 방법으로는 2가지 방법이 있다.

분리 연결법 (Separate Chaining)

배열에 LinkedList를 사용하여 동일한 인덱스를 반환할 경우 List에 추가하는 방식을 사용하여 해시 충돌을 해결할 수 있다.

단, 동일한 인덱스에 너무 많은 데이터가 저장된다면 List를 탐색해야 하기 때문에 성능이 저하될 수 있다.

개방 주소법(Open Addressing)

선형 조사법 (Linear Probing)

해시 충돌이 발생한 배열 방에 다음 비어있는 배열방으로 데이터를 저장하는 방식이다.

배열의 경계를 넘어갈 경우 맨 앞으로 넘어가게 된다.

만약 비어있는 배열방이 없는 경우 빈 배열방을 탐색하는 시간이 늘어나게 된다.

이차원 조사법 (Quadratic Probing)

선형 조사법의 단점을 보완한 방법이 이차원 조사법이다.

선형 조사법에서는 하나씩 배열방을 탐색했다면 이차원 조사법은 제곱으로 빈 배열방을 탐색한다.

특정 영역에 데이터가 몰려도 그 영역을 빠르게 벗어날 수 있는 장점이 있으나 동일한 인덱스를 환산할 경우 탐색해왔던 경로를 그대로 탐색하여 빈 배열방을 찾게 되는 단점이 있다.

더블 해싱 (Double Hashing)

두 개의 해시 함수를 사용하는 방식이다.

인덱스를 반환하여 해시 충돌이 발생하면 다른 해시 함수를 통해 이동할 폭을 얻는다.

해시 함수를 두번 사용하다보니 이동 폭이 같을 확률이 매우 적어 서로 다른 보폭으로 빈 배열 방을 탐색하게 된다.

해시 테이블에서 데이터를 삭제할 때

해시 테이블에서 데이터를 삭제할 때 분리 연결법을 사용할 경우 LinkedList에서 포인터 값을 수정하여 데이터를 제거하거나 추가할 수 있다. 그러나 개방 주소법의 경우 해시 충돌이 발생하게 되면 빈 배열방에 데이터를 저장하게 되는데 기존 인덱스에 저장된 데이터가 삭제될 경우 해당 배열방에 더미 데이터를 통해서 데이터가 지워졌다는 내용을 남기거나 빈 배열방에 저장한 데이터를 다시 기존 배열방에 옮겨주어야 하는 작업이 발생하게 된다.

즉, 데이터 삭제시 분리 연결법이 개방 주소법 보다 성능상 이점을 가지고 있다.

Java에서의 Hash

Java에서는 HashTable과 HashMap을 통해 해시 테이블 자료구조를 제공하고 있다.

HashTable은 Java 1.0에서 추가된 자료구조로 동시성을 보장하나 구현의 거의 변화가 없다.

반면 HashMap의 경우에는 지속적으로 개선되고 있으니 되도록 HashMap을 사용하는 것을 권장한다.

(동시성 문제의 경우 java.util.concurrent 패키지의 라이브러리를 사용하면 된다.)

Java의 해시 충돌 해결 방법

Java는 분리 연결법 (Separate Chaining)을 사용하여 해시 충돌을 해결하고 있다.

단순히 LinkedList를 사용하는 것이 아니라 레드-블랙 트리도 혼용된 방식으로 사용하고 있다.

Java 8부터 해당 방식을 사용하게 되었는데 상수 형태로 기준을 정하게 된다.
동일 버킷에 데이터가 8개가 넘게 되면 LinkedList대신 레드-블랙 트리로 자료구조를 변경한다.
그러다 데이터가 6개가 되면 다시 LinkedList로 자료구조를 변경한다.

2라는 버퍼를 둔 이유는 1개 차이로 데이터의 삽입/삭제가 빈번하게 발생할 경우 불필요한 자료구조 변경으로 인해 성능 저하를 막기 위함이다.

상기에 기술하였듯이 주소 개방법이 데이터 삭제에 있어서 처리가 효율적이지 않기 때문에 Java에서는 분리 연결법을 채택하게 되었다.

버킷에 저장된 데이터가 일정 개수 이상으로 많아지면 일반적으로 주소 개방법이 분리 연결법보다 느리게 되는데 주소 개방법의 경우 버킷을 채운 밀도가 높아질 수록 Worst Case 발생 빈도가 높아지기 때문이다.

주소 개방법의 경우 보조 해시 함수를 통해서 해시 충돌이 발생하지 않도록 조정한다면 Worst Case가 발생하는 것을 줄일 수 있다.

Hash Table Resizing

배열(버킷)에 데이터가 일정 수준 차이게 되면 크기를 늘려줘야 한다.

Java에서 HashMap의 경우 전체 버킷 크기(capacity)가 75%가 차게 되면 버킷의 크기를 2배 늘려주게 된다.

여기서 75%라는 수치를 로드 팩터라고 하는데 HashMap, HashSet등 생성자를 통해 설정해줄 수 있다.

이때 기존 버킷에 저장된 데이터들은 늘어난 버킷 사이즈를 통해 해시 코드와 나머지 연산을 하여 다시 인덱스를 환산해 데이터를 저장하게 된다.

Java에서의 HashMap Resizing

상기에 기술하였듯이 Java에서는 버킷을 resizing할 때 항상 2배로 늘려주게 된다.

이말은 즉, 해시코드와 버킷 갯수를 나머지 연산 할때 해시 코드의 하위 x개의 비트만 사용하게 된다는 말이다.

초록색 박스의 비트를 통해서만 인덱스 환산

해시 함수가 32비트 영역을 고르게 사용하도록 만들었다고 해도 해시 값을 2의 승수로 나누면 해시 충돌이 쉽게 발생하게 된다.

이러한 이유 때문에 Java에서는 보조 해시 함수를 사용하게 된다.

보조 해시 함수

보조 해시 함수는 객체 해시 코드의 상위 16비트 값을 해시코드와 XOR 연산을 해주는 것이다.

보조 해시 함수는 Java 1.4에 등장하여 Java 5 ~ Java 7까지 같은 방식을 사용하다가 Java 8부터 이전 버전에서 사용하던 것보다 단순한 새로운 방식의 보조 해시 함수를 사용한다.

그 이유는 Java 8부터 버킷의 데이터가 많을 경우 레드-블랙 트리를 사용하기 때문에 성능 문제가 완화된 것과 해시 함수 자체가 균등 분포가 잘되게 만들어져 이전 버전에 사용하던 방식이 효과가 크지 않기 때문이다.

인덱스를 반환할 때 HashCode % 버킷 개수 로 연산하는 것이 맞지만 버킷의 개수가 2의 제곱으로 증가할 때는 해시 코드의 하위 x개의 비트만 사용하는 것과 값이 같기 때문에 나머지 연산 대신 HashCode & (버킷의 개수 - 1) 연산을 사용하는 것이 성능상 이점이 있다.
Java에서는 보조 해시 함수를 통해 hashcode를 생성한 이후에 HashCode & (버킷의 개수 - 1) 연산을 하게 된다.

Java에서 Hash를 많이 사용하는 이유

Java는 객체지향 언어이기 때문에 단순히 배열에 데이터를 저장하기 보다는 key-value 구조로 다루는 일이 많으며, 이때 가장 직관적인 자료구조가 Map이다.
- Hash를 사용하게 되면 데이터의 검색, 삽입, 삭제 속도가 빠르기 때문에 HashMap을 자주 사용하게 된다.
Java의 컬렉션 프레임워크가 Hash 기반 구조를 기본으로 제공한다.
Java의 모든 객체의 부모는 Object로 hashCode()와 equals() 메서드를 제공한다.
- 이런 구조 덕분에 Java에서는 Hash 관련 자료구조를 범용적으로 사용할 수 있다.
- C나 C++처럼 해시 함수를 따로 만들어주지 않아도 된다.
Java는 해시 기반 자료 구조를 계속해서 튜닝하여 성능 최적화를 해왔다.

참고

[Java] 메모리 구조로 알아보는 JVM

eeminsu — Fri, 4 Apr 2025 14:54:30 +0900

Runtime Data Area

Runtime Data Area는 JVM의 메모리 구조를 의미하며 총 5가지 영역으로 구분됩니다.

Thread가 모두 공유하는 영역
- Method Area
- Heap
Thread가 독립적으로 사용하는 영역
- Stack
- PC Register
- Native Method Stack

Method Area

java 파일은 Java 컴파일러에 의해 JVM에서 읽을 수 있도록 Java Bytecode로 변환하여 class 파일을 생성합니다.

이렇게 생성된 class 파일은 JVM의 Class Loader에 의해서 JVM 메모리 영역에 클래스 정보를 올리게 되는데

이때 클래스 정보가 올려지는 곳이 Method Area입니다.

Method Area는 크게 아래와 같은 정보를 담고 있습니다.

클래스 구조 정보
- 클래스명, 패키지명, 부모 클래스 정보 등
Runtime Constant Pool
- 리터럴, 심볼 참조(메서드, 필드, 클래스)
필드 정보
메서드 정보
메서드의 바이트코드
static 변수

아래 java 코드를 컴파일하여 Method Area 영역에 올라가는 예시를 보겠습니다.

public class Example {
    public static final String GREETING = "Hello, JVM!";
    private int number;

    public Example(int number) {
        this.number = number;
    }

    public void printGreeting() {
        System.out.println(GREETING + " Your number is: " + number);
    }

    public static void main(String[] args) {
        Example ex = new Example(42);
        ex.printGreeting();
    }
}

Example.java 코드를 실행시키게 되면 위와 같이 Method Area 영역에 클래스 정보가 올라가게 됩니다.

Main 메서드 실행시 Thread가 생성되며 해당 Thread는 Method Area에서 Example 클래스 정보를 참조하여 프로그램을 실행시키게 됩니다.

The Java Virtual Machine Specification(2.5.4) 에서는 Method Area를 Heap의 한 부분으로 기술하지만 Heap과 구분하기 위해 Non-Heap이라고 부르기도 합니다.

JVM 명세에서는 특정 방식을 강제하지 않아 벤더사가 구현 방식을 정하면 되었습니다.

Hotspot VM 개발팀은 Permanent Generation을 구현하여 GC의 수집 범위를 Method Area까지 확장하기로 결정했고 Java 7 이전에는 Method Area를 Permanent Generation에 구현하였습니다.

(참고로 다른 VM은 Permanent Generation라는 개념이 없었습니다. ex-BEA JRockit, IBM j9)

하지만 Permanent Generation은 JVM 시작시 크기가 고정되어 클래스가 많이 로드되면 OOM이 발생하였습니다.

OutOfMemoryError: PermGen space

Java 7에서는 이와 같은 문제를 개선하고자 Permanent Generation(Method Area)에서 관리하던 문자열 상수와 정적 변수등의 정보를 Heap으로 옮겼고, Java 8부터는 Permanent Generation 개념을 지우고 Permanent Generation에 남아있던 모든 정보를 네이티브 메모리에 구현한 Metaspace로 옮겼습니다.

네이티브 메모리에 구현함으로써 OS 메모리만큼 자동으로 확장이 가능하기에 크기가 고정되었던 문제를 해결할 수 있었습니다.

Heap

Heap은 인스턴스 객체와 배열이 저장되는 영역으로 GC의 대상이 되는 영역입니다.

Method Area와 마찬가지로 모든 Thread가 공유하는 영역으로 동시성 이슈가 발생할 수 있습니다.

Heap의 생성된 인스턴스의 참조값은 Stack, Native Method Stack, 상수 풀등에 저장됩니다. (Root Space)

Heap 영역이 가득차게 되면 OutOfMemoryError가 발생하게 됩니다.

상기에 기술하였듯이 JVM의 상세한 구현은 벤더들에게 일임되어 있어 GC뿐만 아니라 Heap의 전반적인 구성도 특별히 정의된바 없이 JVM을 구현하는 벤더에게 전권을 위임하고 있습니다.

(대체로 Hotspot VM이 많이 사용되고 있습니다.)

GC는 세대 단위 컬렉션 이론에 기초해 설계되었습니다.

약한 세대 가설 : 대다수 객체는 일찍 죽는다.
강한 세대 가설 : 가비지 컬렉션 과정에서 살아남은 횟수가 늘어날수록 더 오래 살 가능성이 커진다.
세대 간 참조 가설 : 세대 간 참조의 개수는 같은 세대 안에서의 참조보다 훨씬 적다.

위 이론에 기반하여 Heap 영역을 나누게 되었습니다.

Young Generation
- 새로 생성된 객체가 저장되는 공간
- GC가 가장 자주 발생하는 영역(Minor GC)
- Eden
  - 객체가 처음 생성될 때 저장되는 공간
  - 대부분의 객체가 짧은 생명주기를 가지므로 빠르게 GC 대상이 됩니다.
  - Eden 영역이 꽉 차게 되면 Minor GC가 실행되어 참조가 살아있는 객체는 Survivor(S0 or S1) 영역으로 이동하게 되고 남은 객체는 모두 제거하게 됩니다.
- Survivor
  - Eden 영역에서 살아남은 객체가 이동하는 공간
  - 한 Survivor 영역이 가득 차면 다른 Survivor 영역으로 복사하고 이전 Survivor는 비우게 됩니다.
  - 일정 횟수 이상 참조되어 기준 Age를 넘기면 Old Generation으로 이동하게 됩니다.(Promotion)
  - Survivor 영역 중 하나는 반드시 비어 있어야 함
Old Generation
- Young Gen에서 살아남은 객체들이 이동하는 공간
  - 객체 크기가 크거나 Survivor 영역의 메모리가 부족할 경우 Eden 영역에서 바로 이동할 수도 있습니다.
- 객체의 생명주기가 긴 경우 해당 영역으로 이동하게 됩니다.
- Old Gen에 객체가 가득 차게 되면 Full GC가 실행됩니다.
  - Full GC가 실행하게 되면 GC를 수행하는 Thread를 제외한 모든 Thread가 멈추게 됩니다. -> 이를 stop-the-world라고 합니다.
  - Full GC는 Minor GC보다 느리며 시스템 성능에 영향을 줍니다.
- Old Gen에는 카드 테이블이 존재합니다.
  - Old Gen에 있는 객체가 Young Gen의 객체를 참조할 때마다 정보가 표시되어 Young Gen의 Minor GC가 실행될 때 Old Gen에 있는 모든 객체의 참조를 확인하지 않고 카드 테이블만 확인하여 GC대상을 식별합니다.

하지만 위 영역은 G1 GC가 등장하면서 Region이라는 단위로 나뉘어지게 됩니다.

각 Region 별로 Eden, Survivor, Old등 동적으로 세대를 관리합니다.

Stack

지역변수, 메소드의 매개변수, 리턴 값 등 임시적으로 사용되는 값들이 저장되는 영역으로 PC Register, Native Method Stack과 함께 Thread가 생성될 때마다 독립적으로 할당됩니다.

Stack은 메서드 호출시 생성되는 프레임과 지역 변수 및 메서드 호출에 필요한 정보를 저장하는데 사용 됩니다.

Thread가 메서드 호출시 프레임이 Push되고 메서드 실행이 끝나면 Pop이 됩니다.

메서드 호출이 너무 깊거나 무한 재귀 호출이 일어날 경우 스택의 크기를 초과하여 StackOverFlowError가 발생할 수 있고 Thread 생성시 Stack에 할당할 메모리가 부족하게 되면 OOM이 발생할 수 있습니다.

(해당 내용 관련해서 실제로 OOM이 발생했던 경험을 포스팅한 적이 있으니 참고해주세요! - 링크)

Stack 프레임의 구조는 위 그림을 참고해주세요

Local Variable Array
- 메서드 내에서 선언된 변수나 파라미터 정보를 해당 영역에 저장합니다.
- 지역 변수는 기본 타입의 값(상수 풀)이나 객체에 대한 Refernece(Heap)가 될 수 있습니다.
Operand Stack
- 연산을 위한 임시 공간으로 계산을 할때 필요할 수 있는 값들이 임시로 저장됩니다.
- 메서드 실행 도중 연산을 위해 사용됩니다.
Current Class Constant Pool Reference
- Method Area의 Runtime Constant Pool에 대한 참조입니다.
- 메서드가 속한 클래스의 상수를 사용하기 위해 RCP에 대한 참조값을 가지게 됩니다.

PC Register

Stack과 Native Method Stack과 함께 Thread가 생성될 때 각 Thread마다 할당되는 영역으로 현재 수행중인 JVM의 명령어 주소를 저장합니다.

현재 실행중인 Thread의 바이트코드 줄 번호 표시기라고 생각하면 쉽습니다.

JVM의 명령어 해석(인터프리팅) 과정에서 필수적인 역할을 합니다.

각 Thread마다 독립적인 PC Register를 유지하여 멀티스레드 환경에서도 독립적으로 명령어를 실행시킬 수 있습니다.

Thread가 컨텍스트 스위칭될 때 해당 Thread의 PC Register 값도 저장되고 복원됩니다.

아래 그림을 참고하면 PC Register가 어떤 역할을 하는지 이해할 수 있습니다.

Native Method Stack

JVM이 Java 프로그램에서 네이티브 메서드를 실행할 때 사용하는 스택 영역으로 C, C++ 등으로 작성된 네이티브 코드를 실행할 때 필요하며 JNI(Java Native Interface)를 통해 네이티브 코드를 실행합니다.

JVM은 내부에 많은 OS의 네티이브 라이브러리를 사용하여 구현되는데 JVM 자체적으로 실행할 수 없으며 OS의 네이티브 API를 호출해야 합니다. 이때 Native Method Stack이 필요합니다.

파일 시스템 접근(File I/O), 네트워크 통신(Sockets, HTTP requests), Thread 관리, 메모리 관리 등등

Java 메서드를 실행할 때는 PC Register가 바이트코드의 주소를 저장하지만 Native 메서드가 실행될 때는 PC Register의 값이 특정한 주소를 가리키지 않으며 Undefined 상태가 되고 이에 대한 처리는 Native Method Stack에서 담당합니다.

Stack 영역과 마찬가지로 크기를 초과하면 StackOverflowError가 발생할 수 있습니다.

참고

Java Memory Architecture Cheat Sheet

dzone.com

JVM 밑바닥까지 파헤치기 | 저우즈밍 - 교보문고

JVM 밑바닥까지 파헤치기 | 자바 가상 머신의 깊숙한 내부를 향해 떠나는 흥미진진한 모험C·C++를 사용해 주로 프로그래밍을 하던 시절 까다로운 메모리 관리와 플랫폼 이식성 문제는 개발자들에

product.kyobobook.co.kr

[요약] 멀티 코어를 100% 활용하는 자바 병렬 프로그래밍

eeminsu — Tue, 25 Mar 2025 17:23:24 +0900

리뷰

지금이라도 읽게 돼서 다행이라고 느껴질 정도로 매우 깊은 내용이 담겨있다.

평소에 Thread, ExecutorService를 사용할 줄만 알았지 현재 내가 짠 코드가 스레드 세잎한 상태인지 아닌지도

몰랐던 지난날이 부끄럽다..

책이 출판한지 오래 되어 Java 5, 6을 기준으로 다루긴 하지만 버전과 상관없이 읽기 무방하다.

500p가 넘고 깊이 있는 내용을 다루기 때문에 책이 다소 어렵다.

책에서도 예제 코드와 그림이 상세하게 나와있으나 그럼에도 이해가 되지 않는 부분이 나올 때마다

ChatGPT의 도움을 받아서 예제 코드를 보며 이해를 하곤 했다.

요약

1부 기본원리

상태 없는 객체는 항상 스레드 안전하다.
암묵적인 락은 재진입이 가능하기 때문에 특정 스레드 본인이 이미 획득한 락을 다시 확보할 수 있다.
여러 변수에 대한 불변조건이 있으면 해당 변수들은 모두 같은 락으로 보호해야 한다.
복잡하고 오래 걸리는 계산 작업, 네트워크 작업, 사용자 입출력 작업과 같이 빨리 끝나지 않을 수 있는 작업을 하는 부분에서는 가능한 락을 잡지 말아야한다.

객체 공유

가시성

동기화 되지 않은 상황에서 메모리상의 변수를 대상으로 작성해둔 코드가 반드시 이런 순섯로 동작할 것이다라고 단정지을 수 없다.
락은 상호 배제뿐만 아니라 정상적인 메모리 가시성을 확보하기 위해 사용한다. 각 스레드에서 각자 최신의 정상적인 값으로 활용하려면 동일한 락을 사용해 모두 동기화시켜야 한다.
동기화하고자 하는 부분을 명확하게 볼 수 있고 구혀녀하기가 훨씬 간단한 경우에만 volatile 변수를 활용하자, 반대로 작은 부분이라도 가시성을 추론해봐야 하는 경우에는 volatile 변수를 사용하지 않는 것이 좋다.
락을 사용하면 가시성과 연산의 단일성을 모두 보장받지만 volatile 변수는 연산의 단일성을 보장하지 못한다.

공개와 유출

생성 메소드를 실행하는 도중에는 this 변수가 외부에 유출되지 않게 해야한다.

스레드 한정

특정 객체를 단일 스레드에서만 활용한다고 확신할 수 있다면 해당 객체는 따로 동기화할 필요가 없다
ThreadLocal을 통해 스레드 한정을 형식적으로 구현할 수 있다. ex) JDBC Connection 관리

불변성

객체를 동기화하지 않고도 안전하게 사용할 수 있는 방법
불변 객체는 언제라도 스레드에 안전하다.
불변 객체는 다음 조건을 만족해야 한다.
- 생성되고 난 이후에는 객체의 상태를 변경할 수 없다
- 내부의 모든 변수는 final로 설정돼야 한다.
- 적절한 방법으로 생성 돼야 한다
  - ex) this 변수에 대한 참조가 외부로 유출되지 않아야 한다.

안전 공개

불변 객체는 별다른 동기화 방법을 적용하지 않았다 해도 어느 스레드에서건 마음껏 안전하게 사용할 수 있다. 불변 객체를 공개하는 부분에 동기화 처리를 하지 않았다 해도 아무런 문제가 없다.
객체를 안전하게 공개하려면 해당 객체에 대한 참조와 객체 내부의 상태를 외부의 스레드에게 동시에 볼 수 있어야 한다. 올바르게 생성 메소드가 실행되고 난 객체는 다음과 같은 방법으로 안전하게 공개할 수 있다.
- 객체에 대한 참조를 static 메소드에서 초기화시킨다.
  - JVM에서 클래스를 초기화하는 시점에 작업이 모두 진행된다.
  - 그런데 JVM 내부에서 동기화가 맞춰져 있기 떄문에 객체를 안전하게 공개할 수 있다
- 객체에 대한 참조를 volatile 변수 또는 AtomicReference 클래스에 보관한다.
- 객체에 대한 참조를 올바르게 생성된 클래스 내부의 final 변수에 보관한다.
- 락을 사용해 올바르게 막혀있는 변수에 객체에 대한 참조를 보관한다.
안전하게 공개한 결과적인 불변 객체는 별다른 동기화 작업 없이도 여러 스레드에서 안전하게 호출해 사용할 수 있다.
- 스레드 안전한 컬렉션에 변경 가능한 객체를 가지고 있더라도 해당 객체를 변경하지 않는다면 동기화 코드를 만들 필요가 없다
가변 객체를 사용할 때에는 공개하는 부분과 가변 객체를 사용하는 모든 부분에서 동기화 코드를 작성해야만 한다.
객체를 사용하기 전에 동기화 코드를 적용해 락을 확보해야하는지, 객체 내부의 값을 바꿔도 괜찮은지, 값을 읽기만 해야하는 것인지등 정확하게 알고 있어야 한다.
반대로 객체를 외부에서 사용할 수 있도록 공개할 때에는 해당 객체를 어떤 방법으로 사용할 수 있고 사용해야 하는지에 대해서 정확하게 설명해야 한다.

정리

객체를 공유해 사용하고자 할 때 가장 많이 사용되는 원칙
- 스레드 한정
  - 스레드에 한정된 객체는 완전하게 해당 스레드 내부에 존재하면서 그 스레드에서만 호출해 사용할 수 있다
- 읽기 전용 객체를 공유
  - 읽기 전용이기 때문에 값이 변경될 수 없고 불변 객체와 결과적으로 불변인 객체가 읽기 전용 객체에 해당된다
- 스레드에 안전한 객체를 공유
  - 스레드에 안전한 컬렉션 등
- 동기화 방법 적용
  - 지정한 락을 획득하기 전에는 해당 객체를 사용할 수 없다

객체 구성

스레드 안전한 클래스 설계

클래스가 스레드 안정성을 확보하도록 설계하고자 할때 고려사항
- 객체의 상태를 보관하는 변수가 어떤 것인가
- 객체의 상태를 보관하는 변수가 가질 수 있는 값이 어떤 종류, 어떤 범위에 해당하는가
- 객체 내부의 값을 동시에 사용하고자 할 때 그 과정을 관리할 수 있는 정책
객체가 가질 수 있는 값의 범위와 변동 폭을 정확하게 인식하지 못한다면, 스레드 안정성을 완벽하게 확보할 수 없다.

인스턴스 한정

데이터를 객체 내부에 숨겨두면 숨겨진 내용은 해당 객체의 메소드에서만 사용할 수 있기 때문에 숨겨진 데이터를 사용하고자 할 때에는 항상 지정된 형태의 락이 적용되는지 쉽고 정확하게 파악할 수 있다
인스턴스 한정 기법을 사용하면 전체 프로그램을 다 뒤져보지 않고도 스레드 안정성을 확보하고 있는지 쉽게 분석해 볼수 있기 때문에 스레드에 안전한 객체를 좀 더 쉽게 구현할 수 있다.

스레드 안정성 위임

클래스에 두 개 이상의 변수를 사용하는 복합 연산 메소드를 갖고 있다면 위임 기법만으로는 스레드 안정성을 확볼할 수 없다
이런 경우에는 내부적으로 락을 활용해서 복합 연산이 단일 연산으로 처리되도록 동기화해야한다.
클래스가 서로 의존성 없이 독립적이고 스레드 안전한 두 개 이상의 클래스를 조합해 만들어져 있고 두 개 이상의 클래스를 한번에 처리하는 복합 연산 메소드가 없는 상태라면, 스레드 안정성을 내부 변수에게 모두 위임할 수 있다.
상태 변수가 스레드 안전하고 클래스 내부에서 상태 변수의 값에 대한 의존성을 갖고 있지 않고, 상태 변수에 대한 어떤 연산을 수행하더라도 잘못된 상태에 이를 가능성이 없다면, 해당 변수는 외부에 공개해도 안전하다.

스레드 안전하게 구현된 클래스에 기능 추가

자바 모니터 패턴을 활용해 새로운 클래스 내부에 캡슐화하고 해당 클래스에 들어 있는 스레드 안전한 클래스가 외부로 공개되지 않는 한 스레드 안정성을 확보하면서 기능을 추가할 수 있다.

동기화 정책 문서화하기

구현한 클래스가 어느 수준까지 스레드 안전성을 보장하는지에 대해 충분히 문서를 작성해둬야 한다. 동기화 기법이나 정책을 잘 정리해두면 유지보수 팀이 원활하게 관리할 수 있다.

구성 단위

동기화된 컬렉션 클래스

동기화된 컬렉션 클래스는 대부분 클라이언트 측 락을 사용할 수 있도록 만들어져 있기 때문에 컬렉션 클래스가 사용하는 락을 함께 사용한다면 새로 추가하는 기능을 컬렉션 클래스에 들어있는 다른 메소드와 같은 수준으로 동기화 시킬 수 있다.
반복문에 락을 걸어두게 되면 성능 저하가 발생하며 컬렉션의 수정을 감지할 경우 Exception이 발생한다.
클래스 내부에서 필요한 변수를 모두 캡슐화하면 그 상태를 보존하기가 훨씬 편리한 것처럼 동기화 기법을 클래스 내부에 캡슐화하면 동기화 정책을 적용하기가 쉽다.

병렬 컬렉션

기존에 사용하던 동기화 컬렉션 클래스를 병렬 컬렉션으로 교체하는 것만으로도 별다른 위험 요소 없이 전체적인 성능을 상당히 끌어 올릴 수 있다.

블로킹 큐와 프로듀서-컨슈머 패턴

블로킹 큐는 애플리케이션이 안정적으로 동작하도록 만들고자 할 때 요긴하게 사용할 수 있는 도구이다. 블로킹 큐를 사용하면 처리할 수 있는 양보다 훨씬 많은 작업이 생겨 부하가 걸리는 상황에서 작업량을 조절해 애플리케이션이 안정적으로 동작하도록 유도할 수 있다.

동기화 클래스

래치는 특정한 단일 동작이 완료되기 이전에는 어떤 기능도 동작하지 않도로고 막아내야 하는 경우에 요긴하게 사용할 수 있다
- 특정 자원을 확보하기 전에는 작업을 시작하지 말아야 하는 경우
- 의존성을 갖고있는 다른 서비스가 시작하기 전에는 특정 서비스가 실행되지 않도록 막아야 하는 경우
- 특정 작업에 필요한 모든 객체가 실행할 준비를 갖출 땎가지 기다리는 경우
FutureTask는 Executor 프레임워겡서 비동기적인 작업을 실행하고자 할 때 사용하며, 기타 시간이 많이 필요한 모든 작업이 있을 때 실제 결과가 필요한 시점 이전에 미리 작업을 실행시켜두는 용도로 사용한다.
카운팅 세마포어는 특정 자원이나 특정 연산을 동시에 사용하거나 호출할 수 있는 스레드의 수를 제한하고자 할 떄 사용한다.
- 어떤 클래스라도 크기가 제한된 컬렉션 클래스로 활용할 수 있다.
배리어는 특정 이벤트가 발생할 때까지 여러 개의 스레드를 대기 상태로 잡아 둘 수 있다는 측면에서 래치와 비슷하다.
- 차이점은 모든 스레드가 배리어 위치에 동시에 이르러야 관문이 열리고 계속해서 실행할 수 있다는 점이다.
- 래치는 이벤트를 기다리기 위한 동기화 클래스이고, 배리어는 다른 스레드를 기다리기 위한 동기화 클래스이다.
- 배리어는 대부분 실제 작업은 모두 여러 스레드에서 병렬로 처리하고 담은 단계로 넘어가기 전에 이번 단계에서 계산해야할 내용을 모두 취합해야 하는 등의 작업이 많이 일어나는 시뮬레이션 알고리즘에서 유용하게 사용할 수 있다.(CyclicBarrier)
Exchanger는 두 개의 스레드가 연결되는 배리어이며, 배리어 포인트에 도달하면 양쪽의 스레드가 서로 갖고 있던 값을 교환한다.
- 양쪽 스레드가 서로 대칭되는 작업을 수행할 때 유용하다.

효율적이고 확장성있는 결과 캐시 구현

HashMap을 통해 캐시를 구현한다고 했을 때 동시성을 고려해서 HashMap에 동시에 접근하지 못하도록 메소드 전체를 동기화 시킬 경우 캐시를 적용하니만 못하다 -> 성능이 떨어진다.
HashMap 대신 ConcurrentHashMap을 사용하게 되면 성능상의 문제가 해소되지만 여러 스레드가 동시에 같은 값을 넘기면 같은 작업을 여러번 할 수 있다. 이럴 경우 FutureTask를 사용해서 작업이 진행되고 있다면 작업이 끝날때까지 대기해서 결과를 가져오거나 시작된 작업이 없다면 FutureTask를 만들어서 Map에 등록한다.
하지만 그래도 Map에 결과를 추가할 때 단일 연산이 아니라 복합 연산을 사용하기 때문에 puIfAbsent라는 단일 연산 메소드를 사용해 결과를 저장하면 동시성을 확보하면서 성능도 확보한 캐시를 구현할 수 있다.

1부 요약

상태가 바뀔 수 있다
- 병렬성과 관련된 모든 문제점은 변경 가능한 변수에 접근하려는 시도를 적절하게 조율하는 것으로 해결 할 수 있다. 변경 가능성이 낮으면 낮을수록 스레드 안정성을 확보하기가 쉽다.
변경 가능한 값이 아닌 변수는 모두 final로 선언하라
불변 객체는 항상 그 자체로 스레드 안전하다.
- 불변 객체는 간결하면서 안전하고 락이나 방어적 복사 과정을 거치지 않고도 얼마든지 공유해 사용할 수 있다.
캡슐화하면 복잡도를 손쉽게 제어할 수 있다.
- 데이터를 객체 내부에 캡슐화하면 값이 변경되는 자유도를 쉽게 제어할 수 있다. 객체 내부에서 동기화하는 기법을 캡슐화하면 동기화 정책을 손쉽게 적용할 수 있다.
변경 가능한 객체는 항상 락으로 막아줘야 한다.
불변 조건 내부에 들어가는 모든 변수는 같은 락으로 막아줘야 한다.
복합 연산을 처리하는 동안에는 항상 락을 확보하고 있어야 한다.
여러 스레드에서 변경 가능한 변수의 값을 사용하도록 되어 있으면서 적절한 동기화 기법이 적용되지 않은 프로그램은 올바른 결과를 내놓지 못한다.
동기화할 필요가 없는 부분에 대해서는 일부러 머리를 써서 고민할 필요가 없다.
- 동기화 할 필요가 없다고 이래저래 추측한 결론에 의존해서는 안 된다.
설계 단계부터 스레드 안전성을 염두에 두고 있어야 한다.
- 아니면 최소환 결과물로 작성된 클래스가 스레드에 아전하지 않다고 반드시 문서로 남겨야 한다.
프로그램 내부의 동기화 정책에 대한 문서를 남겨야 한다.

2부 병렬 프로그램 구조 잡기

작업 실행

스레드에서 작업 실행

단일 스레드에서 작업을 순차적으로 실행한다면 높은 처리량과 빠른 반응 속도 모두를 충족하지 못한다.
요청마다 스레드를 생성해서 작업을 처리하게 된다면 자원 낭비, 안정성 문제가 발생할 수 있다.

Executor 프레임웍

프로그램 어디에서든 간에 `new Thread(runnable).start()` 와 같은 코드가 남아있다면 조만간 이런 부분에 유연한 실행 정책을 적용할 준비를 해야할 것이며, 나중을 위해서 Executor를 사용해 구현하는 방안을 심각하게 고려해봐야 한다.
스레드풀을 사용하는 방법에는 많은 장점이 있다.
- 매번 스레드를 생성하지 않고 재사용하기 때문에 여러 개의 요청을 처리하는데 필요한 리소스가 줄어드는 효과가 있다.
- 이미 생성된 스레드가 대기하고 있다가 작업을 처리하기 때문에 딜레이가 발생하지 않아 전체적인 반응 속도도 향상된다.
- 스레드 풀의 크기를 적절히 조절해두면 하드웨어 프로세서가 쉬지 않고 동작할 수 있으며 메모리를 전부 소모하거나 여러 스레드가 한정된 자원을 두고 서로 경쟁하느라 성능을 까먹는 현상도 없앨 수 있다.

병렬로 처리할 만한 작업

유사한 작업 가운데 훨씬 세부적인 작업으로 병렬성을 높이지 못할 바에야, 이런 방법은 전체적인 성능을 떨어뜨리는 결과를 가져올 수 있다.
다양한 종류의 작업을 여러 작업 스레드에서 나눠 처리하도록 할 때는 나눠진 작업이 일정한 크기를 유지하지 못할 수 있다는 단점도 있다.
프로그램이 해야 할 일을 작은 작업으로 쪼개 실행할 때 실제적인 성능상의 이점을 얻으려면 프로그램이 하는 일을 대량의 동일한 작업으로 재정의해 병렬로 처리할 수 있어야 한다.

중단 및 종료

작업 중단

API나 언어 명세 어디를 보더라도 인터럽트가 직압을 취소하는 과정에 어떤 역할을 하는지에 대해 명시되어 있는 부분은 없다. 하지만 실제 상황에서는 작업을 중단하고자 하는 부분이 아닌 다른 부분에 인터럽트를 사용한다면 오류가 발생하기 쉬울 수 밖에 없으며, 애플리케이션 규모가 커질수록 관리하기도 어려워진다.
특정 스레드의 interrupt 메소드를 호출한다 해도 해당 스레드가 처리하던 작업을 멈추지는 않는다. 단지 해당 스레드에게 인터럽트 요청이 있었다는 메시지를 전달할 뿐이다.
인터럽트는 바로 실행 중인 스레드에 실제적인 제한을 가해 멈추도록 하지 않는다, 단지 해당하는 스레드가 상황을 봐서 스스로 멈춰주기를 요청하는 것 뿐이다.
작업 취소 기능을 구현하고자 할 때는 인터럽트가 가장 적절한 방법이라고 볼 수 있다.
각 스레드는 각자의 인터럽트 정책을 갖고 있다. 따라서 해당 스레드에서 인터럽트 요청을 받았을 때 어떻게 동작할지를 정확하게 알고 있지 않은 경우에는 함수로 인터럽트를 걸어서는 안된다.
InterruptedException이 발생했을 때 처리할 수 있는 실질적인 방법
- 발생한 예외를 호출 스택의 사우이 메소드로 전달한다. 이 방법을 사용하는 메소드 역시 인터럽트를 걸수 있는 블로킹 메서드가 된다.
- 호출 스택의 상단에 위치한 메소드가 직접 처리할 수 있도록 인터럽트 상태를 유지한다.
catch 블록에서 InterruptedException을 잡아낸 다음 그대로 먹어버리는 일은 하지 말아야 한다.
- 만약 스레드의 인터럽트 정책을 개별 작업에서 정확하게 구현하고 있다면 아무 일도 하지 않아도 좋다.
스레드의 인터럽트 처리 정책을 정확하게 구현하는 작업만이 인터럽트 요청을 삼켜버릴 수 있다. 일반적인 용도로 작성된 작업이나 라이브러리 메소드는 인터럽트 요청을 그냥 삼켜버려서는 안된다.
Future.get 메소드에서 InterruptedException이 발생하거나 TimeoutException이 발생했을 때, 만약 예외 상황이 발생한 작업의 결과는 필요가 없다고 한다면 해당 작업에 대해 Future.cancel 메소드를 호출해 작업을 중단시켜야한다.
ThreadPoolExecutor클래스의 newTaskFor 메소드를 오버라이드하여 인터럽트 처리를 하게 된다면 작업을 중단하는 과정에서도 응답 속도를 떨어뜨리지 않으면서 인터럽트에 대응하는 블로킹 메소드를 안전하게 호출할 수 있을 뿐만 아니라 대기상태에 들어갈 수 있는 소켓I/O 메소드와 같은 기능도 호출 할 수 있다.

스레드 기반 서비스 중단

스레드 기반 서비스를 생성한 메소드보다 생성된 스레드 기반 서비스가 오래 실행될 수 있는 상황이라면 스레드 기반 서비스에서는 항상 종료시키는 방법을 제공해야 한다.

비정상적인 스레드 종료 상황 처리

잠깐 실행하고 마는 애플리케이션이 아닌 이상 예외가 발생했을 때 로그 파일에 오류를 출력하는 간단한 기능만이라도 확보할 수 있도록 모든 스레드를 대상으로 UncaughtExceptionHandler를 활용해야 한다.

JVM 종료

데몬 스레드는 예고 없이 종료될 수 있기 때문에 애플리케이션 내부에서 시작시키고 종료시키며 사용하기에는 그다지 좋은 방법이 아니다.
finalize 메소드는 사용하지 말자

스레드 풀 활용

작업과 실행 정책 간의 보이지 않는 연결 관계

특정 작업을 실행하고자 할 때 그에 맞는 실행 정책을 요구하는 경우도 있고, 특정 실행 정책 아래에서는 실행되지 않는 경우도 있다. 다른 작업에 의존성이 있는 작업을 실행해야 할 때는 스레드 풀의 크기를 충분히 크게 잡아서 작업이 큐에서 대기하거나 등록되지 못하는 상황이 없도록 해야 한다. 스레드 한정 기법을 사용하는 작업은 반드시 순차적으로 실행돼야 한다. 작업을 구현할 때는 나중에 유지보수를 진행할 때 해당 작업과 호환되지 않는 실행 정책 아래에서 실행하도록 변경해 애프리케이션의 안전성을 해치거나 실행되지 않는 경우를 막을 수 있도록 실행 정책과 관련된 내용을 문서로 남겨야 한다.
완전히 독립적이지 않은 작업을 Executor에 등록할 때는 항상 스레드 부족 데드락이 발생할 수 있다는 사실을 염두에 둬야 하며, 작업을 구현한 코드나 Executor를 설정하는 설정 파일 등에 항상 스레드 풀의 크기나 설정에 대한 내용을 설명해야 한다.

ThreadPoolExecutor 설정

크기가 고정된 풀보다는 newCachedThreadPool 팩토리 메소드가 생성해주는 Executor가 나은 선택일 수 있다. 크기가 고정된 스레드 풀은 자원 관리 측면에서 동시에 실행되는 스레드의 수를 제한해야 하는 경우에 현명한 선택이 될 수 있다. 예를 들어 네트웍으로 클라이언트의 요청을 받아 처리하는 애플리케이션과 같은 경우, 크기가 고정되어 있지 않다면 요청이 많아져 부하가 걸릴 때 문제가 커진다

ThreadPoolExecutor 상속

ThreadPoolExecutor는 beforeExecute, afterExecute, terminated와 같은 훅을 상속하여 사용할 수 있다.

재귀 함수 병렬화

특정 작업을 여러 번 실행하는 반목문이 있을 때, 반복되는 각 작업이 서로 독립적이라면 병렬화해서 성능의 이점을 얻을 수 있다. 특히 반복문 내부의 작업을 개별적인 작업으로 구분해 실행하느라 추가되는 약간의 부하가 부담되지 않을 만큼 적지 않은 시간이 걸리는 작업이라야 더 효과를 볼 수 있다.

GUI 애플리케이션

GUI는 왜 단일 스레드로 동작하는가

스윙의 단일 스레드 규칙 - 스윙 컴포넌트와 모델 객체는 이벤트 스레드 내부에서만 생성하고, 변경하고, 사용할 수 있다.

장시간 실행되는 GUI 작업

이벤트 스레드가 아닌 별도의 백그라운드 작업 스레드에서 작업을 진행하도록 한다.
백그라운드 작업 스레드에서 작업이 완료되면 다시 이벤트 스레드 큐에 작업을 추가한다.
Future 혹은 Future 태스크를 통해서 작업이 완료된 사항을 쉽게 처리할 수 있다.

데이터 공유 모델

데이터 모델을 여러 개의 스레드에서 공유해야 하는 경우라면 분할 데이터 모델을 사용하는 방법을 고려해보자, 스레드 안전하게 공유할 수 있는 데이터 모델을 만들어 사용하고자할 때 대기 상태에 들어가는 블로킹 문제, 일관성 문제, 구현하기에 복잡하다는 이유 등이 있다면 스레드 안전한 모델 대신 분할 데이터 모델을 추천한다.

3부 활동성, 성능, 테스트

활동성을 최대로 높이기

데드락

프로그램 내부의 모든 스레드에서 필요한 락을 모두 같은 순서로만 사용한다면, 락 순서에 의한 데드락은 발생하지 않는다.
락을 확보한 상태에서 에일리언 메소드를 호출한다면 가용성에 문제가 생길 수 있다. 에일리언 메소드 내부에서 다른 락을 확보하려고 하거나, 아니면 예상하지 못한 만큼 오랜 시간 동안 계속해서 실행된다면 호출하기 전에 확보했던 락이 필요한 다른 스레드가 계속해서 대기해야 하는 경우도 생길 수 있다.
오픈 호출(락을 전혀 확보하지 않은 상태에서 메소드를 호출하는 것)만을 사용해야 한다거나 락을 확보하는 순서를 주의 깊게 정해야 한다는 사실은, 여러 객체가 조합된 코드의 동기화를 맞추는 것보다 동기화가 맞춰진 객체를 조합해 사용하는 것이 훨씬 복잡하다는 것을 의미한다.
프로그램을 작성할 때 최대한 오픈 호출 방법을 사용하도록 한다. 내부의 모든 부분에서 오픈 호출을 사용하는 프로그램은 락을 확보한 상태로 메소드를 호출하곤 하는 프로그램보다 데드락 문제를 찾아내기 위한 분석 작업을 훨씬 간편하게 해준다.

데드락 방지 및 원인 추적

두 개의 락을 한꺼번에 확보해야 하는 경우에 타임아웃을 지정하는 방법을 적용하면, 프로그램 전체에서 모두 타임아웃을 사용하지 않는다 해도 데드락을 방지하는 데 효과를 볼 수 있다.

그 밖의 활동성 문제점

스레드 우선 순위를 변경하고 싶다 해도 꾹 참자, 우선 순위를 변경하고 나면 플랫폼에 종속적인 부분이 많아지며, 따라서 활동성 문제를 일으키기 쉽다, 대부분의 병렬 애플리케이션은 모든 스레드의 우선 순위에 기본값을 사용하고 있다.
서로 락을 획득한 상태에서 상대방의 락을 기다리다가 타임아웃이 발생했을 때 재시도를 계속해서 시도하지만 결국 자원을 얻지 못하는 상태를 라이브락이라고 한다, 이럴 경우 재시도할 때 잠시 기다리는 시간을 임의로 지정하게 되면 라이브락을 방지할 수 있다.

성능, 확장성

성능에 대해

확장성은 CPU, 메모리, 디스크, I/O 처리 장치 등의 추가적인 장비를 사용해 처리량이나 용량을 얼마나 쉽게 키울 수 있는지를 말한다.
최적화 기법을 너무 이른 시점에 적용하지 말아야 한다, 일단 제대로 동작하게 만들고 난 다음에 빠르게 동작하도록 최적화해야 하며, 예상한 것보다 심각하게 성능이 떨어지는 경우에만 최적화 기법을 적용하는 것으로도 충분하다.
특정 방법이 다른 방법보다 빠르다고 말하기전에 다음과 같은 질문에 대답해 볼 필요가 있다.
- 빠르다 단어가 무엇을 의미하는가
- 어떤 조건을 갖춰야 이 방법이 실제로 빠르게 동작할 것인가
  - 부하가 적을 때?, 부하가 걸릴 때?, 데이터가 많을 때?. 데이터가 적을 때?
  - 이런 질문에 대한 대답에 명확한 수치를 보여줄 수 있는가
- 위 조건에 해당하는 경우가 얼마나 많이 발생하는가
  - 이런 질문에 대한 대답에 명확한 수치를 보여줄 수 있는가
- 조건이 달라지는 다른 상황에서도 같은 코드를 사용할 수 있는가
- 이 방법으로 성능을 개선하고자 할 때 숨겨진 비용, 즉 개발 비용이나 유지보수 비용이 증가하는 부분이 어느정도인지, 그런 비용을 감수함녀서까지 성능 개선 작업을 해야하는가?
추측하지 말고 실제로 측정해보자

암달의 법칙

모든 병렬 프로그램에는 항상 순차적으로 실행돼야만 하는 부분이 존재한다. 만약 그런 부분이 없다고 생각한다면, 프로그램 코드를 다시 한 번 들여다보자.

스레드와 비용

경쟁 조건에 들어가지 않는 동기화 블록에 대해서는 그다지 걱정하지 않아도 좋다. 동기화 블록의 기본적인 구조가 상당히 빠르게 동작할 뿐만 아니라 JVM 수준에서 동기화와 관련한 추가적인 최적화 작업을 진행하기 때문에 동기화 관련 부하를 줄이거나 아예 없애주기도 한다. 대신 경쟁 조건이 발생하는 동기화 블록을 어떻게 최적화할지에 대해서 고민하자

락 경쟁 줄이기

병렬 애플리케이션에서 확장성에 가장 큰 위협이 되는 존재는 바로 특정 자원을 독점적으로 사용하도록 제한하는 락이다.
락 경쟁 조건을 줄일 수 있는 몇가지 방법이 있다.
- 락을 확보한 채로 유지되는 시간을 최대한 줄여라
- 락을 확보하고자 요청하는 횟수를 최대한 줄여라
- 독점적인 락 대신 병렬성을 크게 높여주는 여려 가지 조율 방법을 사용하라
락을 하나에서 둘로 분할하는 방법은 경쟁 조건이 아주 심하지는 않지만 그래도 어느 정도 경쟁이 발생하고 있는 경우에 가장 큰 효과를 볼 수 있다. 만약 경쟁 조건이 심한 락을 두개로 분할하고 나면 결국 경쟁이 심한 락이 두개가 생기는 모양새가 될 수 있다.
스레드 동기화하는 것 보다 메모리에 객체를 할당하는 일이 훨씬 부담이 적다.

컨텍스트 스위치 부하 줄이기

요청을 처리하는 스레드의 외부로 I/O 작업을 뽑아내는 방법은 요청을 처리하는 평균 시간을 줄여주는 좋은 방법이다. 예를 들어 log 메소드를 호출하는 스레드는 더 이상 출력 스트림에 대한 락을 확보할 필요도 없고 I/O 작업이 완료될 때까지 대기하지 않아도 된다.
로그를 출력하고자 요청하는 다수의 스레드에서 발생할 I/O 연산을 단 하나의 스레드에서 처리하도록 한군데로 몰아두기 때문에 로그 출력 스트림을 공유하지 않아도 되고 따라서 대기 상태에 들어갈 수 있는 원인을 미연에 방지하고 있다.

import java.util.concurrent.BlockingQueue;
import java.util.concurrent.LinkedBlockingQueue;

class AsyncLogger {
    private static final BlockingQueue<String> logQueue = new LinkedBlockingQueue<>();
    private static final Thread logThread;

    static {
        logThread = new Thread(() -> {
            while (true) {
                try {
                    String logMessage = logQueue.take();  //   큐에서 로그 메시지 가져오기
                    System.out.println(logMessage);  //   단일 스레드에서만 로그 출력
                } catch (InterruptedException e) {
                    Thread.currentThread().interrupt();
                    break;
                }
            }
        });

        logThread.setDaemon(true); // 프로그램 종료 시 자동 종료
        logThread.start();
    }

    public static void log(String message) {
        logQueue.offer(message);  //   로그 메시지를 큐에 추가 (즉시 반환, 블로킹 없음)
    }
}

class RequestHandler implements Runnable {
    private final int requestId;

    public RequestHandler(int requestId) {
        this.requestId = requestId;
    }

    @Override
    public void run() {
        long startTime = System.currentTimeMillis();
        AsyncLogger.log("Request " + requestId + " started.");  //   로그는 별도 스레드로 넘김

        //   I/O 작업을 직접 수행하는 대신 비동기적으로 실행
        new Thread(() -> {
            try {
                Thread.sleep(100); //   가상의 I/O 작업 (100ms)
                AsyncLogger.log("Request " + requestId + " completed.");
            } catch (InterruptedException e) {
                Thread.currentThread().interrupt();
            }
        }).start();

        long elapsedTime = System.currentTimeMillis() - startTime;
        System.out.println("Request " + requestId + " handled in " + elapsedTime + "ms.");
    }
}

public class Main {
    public static void main(String[] args) {
        for (int i = 1; i <= 5; i++) {
            new Thread(new RequestHandler(i)).start();  //   요청 스레드 여러 개 실행
        }
    }
}

병렬 프로그램 테스트

정확성 테스트

Thread.getState 메소드를 병렬성을 제어하는 용도로 사용하지 말아야 한다. JVM의 구현 방법에 따라 스핀 대기 기법을 활용할 수도 있으므로 특정 스레드가 대기 상태에 들어갔다고 해서 항상 스레드가 WAITING 또는 TIMED_WAITING 상태에 놓여있다고 볼 수 없기 때문이다.
안전성을 테스트하는 프로그램을 효과적으로 작성하려면 뭔가 문제가 발생해을 때 잘못 사용되는 속성을 높은 확률로 찾아내는 작업을 해야 함과 동시에 오류를 확인하는 코드가 테스트 대상의 병렬성을 인위적으로 제한해서는 안 된다는 점을 고려해야 한다. 테스트하는 대상 속성의 값을 확인할 때 추가적인 동기화 작업을 하지 않아도 된다면 가장 좋은 상태라고 볼 수 있다.
테스트 프로그램은 스레드가 교차 실행되는 경우의 수를 최대한 많이 확보할 수 있도록 CPU 가 여러 개 장착된 시스템에서 돌려보는 게 좋다. 그렇다고 CPU가 수십 개 달렸다고 해서 서너 개의 CPU가 장착된 시스템에 비해 테스트 효율이 좋아진다고 보기는 어렵다. 절묘한 타이밍에 공유된 데이터를 사용하다 나타나는 오류를 찾으려면 CPU가 많이 있는 것보다 스레드를 더 많이 돌리는 편이 낫다. 스레드가 많아지면 실행 중인 스레드와 대기 상태에 들어간 스레드가 서로 교차하면서 스레드 간의 상호 작용이 발생하는 경우의 수가 많아지기 때문이다.

성능 측정의 함정 피하기

훌륭한 성능 측정 프로그램을 작성하려면 최적화 컴파일러가 의미 없는 코드를 제거하는 과정에 성능 측정상 필요한 부분까지 제거하지 않도록 약간의 편법을 써야 할 필요가 있다. 그러려면 프로그램 코드가 만들어내는 모든 결과 값을 프로그램 어디에선가 사용하도록 해야 한다. 물론 그 때문에 추가적으로 동기화를 해야 하거나 더 많은 자원을 소모하도록 하지는 않는 것이 좋다.

4부 고급 주제

명시적인 락

Lock과 ReentrantLock

락을 확보하고자 대기하고 있는 상태의 스레드에는 인터럽트 거는일이 불가능하고 대기 상태에 들어가지 않으면서 락을 화보하는 방법등이 꼭 필요한 상황이 있기 때문에 명시적인 락 클래스를 따로 만들게 된 것이다.
ReentrantLock을 사용하면 해당하는 블록의 실행이 끝나고 통제권이 해당 블록을 떠나는 순간 락을 자동으로 해제하지 않기 때문에 굉장히 위험한 코드가 될 가능성이 높다, 락을 블록이 끝나는 시점에 finally 블록을 사용해 해제해야 한다.

성능에 대한 고려 사항

성능 측정 결과는 우미깅는 대상이다. 바로 어제 X가 Y보다 빠르다는 결과를 산출했던 성능 테스트를 오늘 실행해보면 다른 결과를 얻을 수도 있다.

공정성

대부분 공정하게 순서를 관리해서 얻는 장점보다 불공정하게 처리해서 얻는 성능상의 이점이 크다.

synchronized 또는 ReentrantLock 선택

ReentrantLock은 암묵적인 락만으로는 해결할 수 없는 복잡한 상황에서 사용하기 위한 고급 동기화 기능이다. 다음과 같은 고급 동기화 기법을 사용해야하는 경우에만 ReentrantLock을 사용하도록 하자
- 락을 확보할 때 타임아웃을 지정해야 하는 경우
- 폴링의 형태로 락을 확보하고자 하는 경우
- 락을 확보하느라 대기 상태에 들어가 있을 때 인터럽트를 걸 수 있어야 하는 경우
- 대기 상태 큐 처리 방법을 공정하게 해야 하는 경우
- 코드가 단일 블록의 형태를 넘어서는 경우

읽기-쓰기 락

읽기 작업은 여러 개를 한꺼번에 처리할 수 있지만 쓰기 작업은 혼자만 동작할 수 있는 구조의 동기화를 처리해주는 락

동기화 클래스 구현

조건 큐 활용

조건 큐를 올바로 사용하기 위한 가장 핵심적인 요소는 바로 해당 객체가 대기하게 될 조건 서술어를 명확하게 구분해내는 일이다.
조건 큐와 연결된 조건 서술어를 항상 문서로 남겨야 하며, 그 조건 서술어에 영향을 받는 메소드가 어느 것인지도 명시해야 한다.
wait 메소드를 호출하는 모든 경우에는 항상 조건 서술어가 연결돼 있다. 특정 조건 서술어를 놓고 wait 메소드를 호출할 때 호출자는 항상 해당하는 조건 큐에 대한 락을 이미 확보한 상태여야 한다. 또한 확보한 락은 조건 서술어를 확인하는 데 필요한 모든 상태 변수를 동기화하고 있어야 한다.
조건부 wait 메서드를 사용할 때에는
- 항상 조건 서술어(작업을 계속 진행하기 전에 반드시 확인해야 하는 확인 절차)를 명시해야 한다.
- wait 메소드를 호출하기 전에 조건 서술어를 확인하고 wait에서 리턴된 이후에도 조건 서술어를 확인해야 한다.
- wait 메소드는 항상 반복문 내부에서 호출해야 한다.
- 조건 서술어를 확인하는 데 관련된 모든 상태 변수는 해당 조건 큐의 락에 의해 동기화돼 있어야 한다.
- wait, notify, notifyAll 메소드를 호출할 때는 조건 큐에 해당하는 락을 확보하고 있어야 한다.
- 조건 서술어를 확인한 이후 실제로 작업을 실행해 작업이 끝날 때까지 락을 해제해서는 안 된다.
특정 조건을 놓고 wait 메소드를 호출해 대기 상태에 들어간다면 해당 조건을 만족하게 된 이후에 반드시 알림 메소드를 사용해 대기 상태에서 빠져나오도록 해야 한다.
notifyAll 대신 notify 메소드를 사용하려면 다음과 같은 조건에 해당하는 경우에만 사용하는 것이 좋다
- 단일 조건에 따른 대기 상태에서 깨우는 경우
  - 해당하는 조건 큐에 단 하나의 조건만 사용하고 있는 경우이고, 따라서 각 스레드는 wait 메소드에서 리턴될 때 동일한 방법으로 실행된다.
- 한 번에 하나씩 처리하는 경우
  - 조건 변수에 대한 알림 메소드를 호출하면 하나의 스레드만 실행시킬 수 있는 경우

명시적인 조건 객체

암묵적인 조건 큐를 일반화한 형태는 Condition 클래스이다
암묵적인 락에서 사용하던 wait, notify, notifyAll 메소드의 기능은 Condition 클래서에서는 각각 await, signal, signalAll 메소드이다. 자바에서 모든 클래스가 그렇지만 Condition 클래스 역시 Object를 상속받기 때문에 Condition 객체에도 wait, notify, notifyAll 메소드가 포함돼 있다. 따라서 실수로 await 대신 wait 메소드를 사용하거나 notify 대신 signal 메소드를 사용하면 동기화 기능에 큰 문제가 생길 수 있다.
Condition객체 사용 유무는 ReentrantLock과 synchronized의 선택 문제와 같다.

동기화 클래스의 내부 구조

AbstractQueuedSynchronizer는 락이나 기타 동기화 클래스를 만들수 있는 프레임웍 역할을 한다.
AQS 기반으로 만들어진 동기화 클래스는 대기 상태에 들어갈 수 있는 지점이 단 한군데이기 때문에 컨텍스트 스위칭 부하를 줄일 수 있고 결과적으로 전체적인 성능을 높일 수 있다.

단일 연산 변수와 넌블로킹 동기화

락의 단점

경쟁이 심한 상황이 되면 컨텍스트 스위칭 부하와 함께 스케줄링 관련 지연 현상이 발생하면서 성능이 떨어진다, 락을 아주 짧은 시간만 사용할 경우 그 작업을 위해서 스레드를 대기 상태에 들어가게 하는 일이 굉장한 단점이 될 수 있다.
또 다른 단점은 스레드가 락을 확보하기 위해 대기하고 있는 상태에서 대기 중인 스레드는 다른 작업을 전혀 못한다.

병렬 연산을 위한 하드웨어적인 지원

CAS(compare and swap)은 대상 메모리 위치에 들어 있는 값이 예상하는 기존값이라고 생각되며, 만약 실제로 대상 메모리 위치의 값이 예상하는 기존값이라면 새로 설정한 값으로 바꿔 넣어라, 만약 대상 메모리 위치의 값이 예상하는 기존값이 아니라면 아무 작업도 하지 말고 대상 메모리 위치의 값이 뭔지 알려다라는 연산으로 낙관적인 기법이다.
만약 여러 스레드가 동시에 CAS 연산을 사용해 한 변수의 값을 변경하려고 한다면, 스레드 가운데 하나만 성공적으로 값을 변경하고 나머지 스레드는 모두 실패한다.
CAS 연산을 사용하면 다른 스레드와 간섭이 발생했는지를 확인할 수 있기 때문에 락을 사용하지 않으면서도 읽고-변경하고-쓰는 연산을 단일 연산으로 구현해야한다는 문제를 간단하게 해결해준다.
CAS 연산을 프로그램에서 직접 사용하면 JVM에서 특별한 루틴을 실행해야 할 필요도 없고 운영체제의 함수를 호출해야 할 필요도 없고 스케줄링 관련 작업을 따로 조절해야 할 필요도 없다, 애플리케이션 수준에서는 코드가 더 복잡해 보이지만 JVM이나 운영체제의 입장에서는 훨씬 적은 양의 프로그램만 실행하는 셈이다.

단일 연산 변수 클래스

확장성을 가장 높일 수 있는 방법은 스레드 간의 경쟁이 발생하지 않도록 미연에 방지하는 방법이다.
- EX) ThreadLocal

넌블로킹 알고리즘

넌블로킹 알고리즘은 데드락이나 우선 순위 역전등의 문제점이 발생하지 않지만 지속적으로 재시도만 하고 있을 가능성이 이씩 때문에 라이브락의 문제점이 발생할 가능성이 있다.
넌블로킹 알고리즘을 작성할 때 핵심은 단일 연산의 범위를 단 하나의 변수로 제한하는 부분이다.

자바 메모리 모델

자바 메모리 모델은 무엇이며, 왜 사용해야 하는가?

미리 발생 현상에 대한 규칙
- 프로그램 순서 규칙
  - 특정 스레드를 놓고 봤을 때 프로그램된 순서에서 앞서있는 작업은 동일 스레드에서 뒤에 실행되도록 프로그램된 작업보다 미리 발생한다.
- 모니터 잠금 규칙
  - 특정 모니터 잠금 작업이 뒤이어 오는 모든 모니터 잠금 작업보다 미리 발생한다.
- volatile 변수 규칙
  - volatile 변수에 대한 쓰기 작업은 이후에 따라오는 해당 변수에 대한 모든 읽기 작업보다 미리 발생한다.
- 스레드 시작 규칙
  - 특정 스레드에 대한 Thread.start 작업은 시작된 스레드가 갖고 있는 모든 작업보다 미리 발생한다.
- 스레드 완료 규칙
  - 스레드 내부의 모든 작업은 다른 스레드에서 해당 스레드가 완료됐다는 점을 파악하는 시점보다 미리 발생한다. 특정 스레드가 완료됐는지를 판단하는 것은 Thread.join 메소드가 리턴되거나 Thread.isAlive 메소드가 false를 리턴하는지 확인하는 방법을 말한다.
- 인터럽트 규칙
  - 다른 스레드를 대상으로 interrupt 메소드를 호출하는 작업은 인터럽트 당한 스레드에서 인터럽트를 당했다는 사실을 파악하는 일보다 미리 발생한다. 인터럽트를 당했다는 사실을 파악하려면 InterruptedException을 받거나 isInterrupted 메소드 또는 interrupted 메소드를 호출하는 방법을 사용할 수 있다.
- 완료 메소드 규칙
  - 특정 객체에 대한 생성 메소드가 완료되는 시점은 완료 메소드가 시작하는 시점보다 미리 발생한다.
- 전이성
  - A가 B보다 미리 발생하고, B가 C보다 미리 발생한다면, A는 C보다 미리 발생한다.

안전한 공개

불변 객체가 아닌 이상 특정 객체를 공개하는 일이 그 객체를 사용하려는 작업보다 미리 발생하도록 구성돼 있지 않다면 다른 스레드에서 생성한 객체를 사용하는 작업은 안전하지 않다.

초기화 안전성

초기화 안전성이 확보돼 있다면 완전하게 구성된 객체를 대상으로 해당 객체가 어떻게 공개됐던 간에 생성 메소드가 지정하는 모든 final 변수의 값을 어떤 스레드건 간에 올바르게 읽어갈 수 있다는 점을 보장한다. 또한 완전하게 구성된 객체 내부에 final로 선언된 객체를 거쳐 사용할 수 있는 모든 변수(예를 들어 final로 선언된 배열의 항목 또는 final로 선언된 HashMap 내부에 들어 있는 값 등) 역시 다른 스레드에서 안전하게 볼 수 있다는 점도 보장된다.
초기화 안전성은 생성 메소드가 완료되는 시점에 final로 선언된 변수와 해당 변수를 거쳐 접근할 수 있는 값에 대해서만 가시성을 보장한다. final로 선언되지 않은 변수나 생성 메소드가 종료된 이후에 변경되는 값에 대해서는 별도의 동기화 구문을 적용해야 가시성을 확보할 수 있다.

[Spring Boot] AWS Opensearch를 사용하다 OOM을 만나다.

eeminsu — Sun, 12 Jan 2025 18:47:40 +0900

이 글은 Java/Spring Boot 기반 서비스를 운영하며 Thread 누수 문제를 분석하고 해결한 과정을 기록한 글입니다.

1. 문제 발생

Caused by: java.lang.OutOfMemoryError: unable to create native thread: possibly out of memory or process/resource limits reached
	at java.base/java.lang.Thread.start0(Native Method)
	at java.base/java.lang.Thread.start(Thread.java:1526)
	at java.base/java.util.Timer.<init>(Timer.java:188)

java.lang.OutOfMemoryError: unable to create native thread

위 에러는 Java에서 너무 많은 Thread를 생성하여 더 이상 Thread를 생성할 수 없을 때 발생하는 에러이다.

갑자기 API 호출이 계속해서 실패하여 로그를 확인해보니 위 에러가 발생하고 있었다.

이상했다. 여태 이상없이 잘 돌고 있던 서비스에서 갑자기 OOM이 간헐적으로 터졌다.

로드 밸런싱 처리도 되어있고 트래픽도 높지 않았다.

원인이 무엇일까?

2. 원인 분석

우선 Thread 생성 관련 OOM이 발생했다는 것은 Thread가 점진적으로 계속 생성만 되고 종료되지 않는다는 뜻이다.

정확한 원인 분석을 위해 VisualVM을 통해 활성 Thread를 모니터링 했다.

(문제가 발생했을 당시 Thread 덤프를 떠놓지 않아 정상적인 Thread 모니터링 이미지로 대체..)

I/O dispatcher Thread가 특정 간격으로 점진적으로 쌓이고 있는 것을 발견했다.

그렇다면 뭐 때문에 이렇게 Thread가 쌓이는지 다시 API 서버 로그를 확인해보니,

AWS Opensearch에서 데이터를 조회하는 API를 호출할 때 마다 Thread가 쌓이고 있는 것을 확인했다.

3. 증가하는 Thread 분석

점진적으로 쌓이던 Thread(I/O dispatcher)도 확인했고 Thread를 쌓이게 만들었던 원인(AWS Opensearch)도 발견했다.

그렇다면 이 둘은 무슨 관계가 있는걸까?

해당 프로젝트는 Opensearch-client를 사용했다.

아래와 같이 OpenSearchClient를 생성한 후 사용해야한다.

publci OpenSearchClient openSearchClient() {
        final CredentialsProvider credentialsProvider = new BasicCredentialsProvider();
        credentialsProvider.setCredentials(AuthScope.ANY, new UsernamePasswordCredentials(openSearchId, openSearchPassword));

        RestClient restClient = RestClient.builder(new HttpHost(openSearchHost, openSearchPort, "https"))
                .setHttpClientConfigCallback(
                        httpClientBuilder -> httpClientBuilder.setDefaultCredentialsProvider(credentialsProvider)
                )
                .build();

        RestClientTransport transport = new RestClientTransport(restClient, new JacksonJsonpMapper());
        return new OpenSearchClient(transport);
    }

RestClinet를 생성할 때 HttpAsyncClientBuilder를 통해 CloseableHttpAsyncClient 추상 클래스를 구현 InternalHttpAsyncClient를 생성하여 사용하게 된다.

이 때, Connection 관리 및 네트워크 I/O 처리를 위해 IOReactor를 사용하게 되면서 I/O Dispatch Thread가 생성되게 된다.

httpClientBuilder -> httpClientBuilder.setDefaultCredentialsProvider(credentialsProvider)
                                .setDefaultIOReactorConfig(IOReactorConfig.custom()
                                .setIoThreadCount(1)
                                .build())

위 처럼 IOReactor에서 사용할 Thread의 개수도 설정할 수 있다.

만약, 설정하지 않을 시 서버 CPU의 코어 수를 기반으로 I/O Thread가 생성된다.

//IOReactorConfig.class

public static int getDefaultMaxIoThreadCount() {
    return DefaultMaxIoThreadCount > 0 ? DefaultMaxIoThreadCount : Runtime.getRuntime().availableProcessors();
}

점진적으로 쌓이던 Thread(I/O dispatcher)와 Thread를 쌓이게 만들었던 원인(AWS Opensearch)의 상관관계도 파악했다.

그렇다면 왜 에러가 발생한걸까?

4. 결론

생각보다 허무했고 어이가 없었다.

OpenSearchClient를 Bean으로 관리하지 않고 조회시 마다 Client를 새로 생성하며 발생한 문제였다.(너무 어처구니 없었다..)

심지어 IOReactor의 설정도 되어있지 않아 CPU 코어 수 만큼 Thread가 생성되고 있던 것이었다.

기존에는 잘 사용되지 않던 API가 갑자기 사용량이 늘면서 뒤늦게서야 문제를 파악하게 된 것이다.

OpenSearchClient를 사용할 땐 꼭 Bean으로 등록하거나 Client를 사용하고 나면 꼭 Close를 해주자..

opensearch._transport().close();

8. Instructions: Language of the Computer 4

eeminsu — Wed, 14 Apr 2021 22:54:35 +0900

KOCW 최규상 교수님 컴퓨터구조 강의 정리
이 글은 공부한 것을 복습 및 기록하기 위한 게시물입니다.
잘못된 정보가 기입되어 있을 수 있으니 주의해주시기 바랍니다.

참고 : 컴퓨터 구조 및 설계 - David A. Patterson,John L. Hennessy
강의 링크 : http://www.kocw.net/home/cview.do?lid=f64448266743ced9

1. 32-bit Constants

MIPS에서는 immediate는 16bit이다.
32 bit을 처리하기 위해선 2개의 instructuion이 필요하게 된다.

lui rt, constant
상수값이 target register의 상위 16bit로 복사된다.

ori $s0, $s0, 2304
상수값이 target register의 하위 16bit로 복사된다.

2개의 instruction을 통해 32bit 상수를 만들 수 있게 되는 것이다.

2. Branch Addressing

branch는 특정한 target address가 있다.
branch instruction의 32bit은 4개의 영역으로 나뉘게 된다
op, rs, rt, constant or address

branch에서 이동할 target address를 수식을 통해 계산할 수 있다.
이를 PC-relative addressing이라 한다.
공식은 아래와 같다.

PC(Program Counter) + offset(constant or address) × 4
Program Counter의 경우에는 이미 프로그램이 실행하고 있을 시
다음 address를 가리키고 있으므로 이미 4byte 증가해있다.
이를 고려하여 계산을 해야 한다.

3. Jump Addressing

Jump instruction의 32 bit는 2영역으로 나뉘게 된다.
op, address
opcode는 항상 6bit이며 address는 26bit이다.

이런 방식의 addressing을 (Pseudo)Direct jump addressing 이라고 한다.

address는 32bit이다.
target address는 현재 PC에 들어있는 상위 4bit이 그대로 가져오고(PC의 주소와 JUMP 목적지가 인접할 것이라 가정)
address는 항상 4byte 단위로 움직이기 때문에 하위 2bit는 생략하여 표현이 가능하다.
하위 28bit는 26bit * 4를 하게 되면 28bit가 된다.
그래서 28bit와 4bit를 합쳐 target address를 구성하게 된다.

4. Target Addressing Example

Loop가 80000번지에 위치해있고 그림과 같이 instruction들이 배치 되어있다.

instruction간 주소는 4의 배수이다.
bne $t0, $s5, Exit의 constant or address 영역은 2이다.
이 constant or address 영역은 branch instruction의 도착점이 PC에서 일정 거리 이내이 있을거라는
가정 하에 PC에서 목적지까지의 차이를 저장한다.

PC는 항상 다음 instruction의 주소를 가리킨다.
즉, 현재 bne $t0, $s5, Exit의 주소는 80012이고 그다음 번지는 80016이다.
80016에서 다음 2번째가 바로 Exit의 주소이다.

즉, target address의 공식에 대입하게 되면 80016 + (2 * 4) = 80024가 된다.

j Loop의 address영역은 20000이다.
공식에 대입하게 되면 20000 * 4 = 80000이 된다.
(Pseudo)Direct jump addressing 또한 PC에서의 앞 4bit를 가져온다.
PC에 저장된 주소와 jump 목적지가 인접할 것이라고 가정한다.
즉, 상위 4bit은 0000 이므로 80000이 된다.

lw $t0, 0($t1) 의 constant는 ($t1)의 앞에 붙어있는 값이다.

5. Branching Far Away

Branch는 때때로 Branc target이 너무 멀리 있어 16bit offset값을 넘을 때가 있다.

이런 경우 어셈블러는 beq $s0,$s1, L1 을 아래와 같이 바꿔준다.
bne $s0,$s1, L2
j L1

Branch instruction 대신 jump instruction을 쓰게 된다.
jump는 26bit를 커버하기 때문에 훨씬 멀리 있는 곳 까지 jump 할 수 있다.

6. Addressing Mode Summary

MIPS에는 5가지 addressing mode가 존재한다.

immedate addressing : addi ...
register addressing : R-type ...
base addressing : lw, sw ...
PC-relative addressing : branch ...
(Pseudo)Direct jump addressing: jump ...

7. Synchronization

최근에 나온 프로세서는 멀티코어이다.
이럴 경우 서로다른 코어가 하나의 메모리 공간을 공유할 수 있다.
Race condtion이 발생할 수 있기 때문에 엑세스 순서를 잘 지켜줘야 한다.

이런 문제 해결을 위해 H/W의 도움이 필요하게 된다.

대표적인 예로 Atomic read/write memory가 있다.
Atomic은 어떤 operation을 할때 중간에 인터럽트가 발생하지 않는 것이다.
한번 명령어가 시작하면 인터럽트 없이 명령어를 완료하는 것이다.
이런 경우 read와 write사이에 다른 location에 대한 엑세스를 허용하지 않는 것이다.

spin lock을 구현할 때 Atomic read/write memory operation 을 지원해주는 single instruction을 사용한다.
atomic swap of register
atomic pair

이런식으로 인터럽트가 발생하지 않도록 해준다.
즉, 2개의
이 하나로 되게끔 해주는 것이다.

7-1. Synchronization in MIPS

MIPS에서는 Load linked: ll rt, offset(rs) 명령어가 Atomic operation이다.
이런 명령어를 사용해서 Synchronization 명령어를 만들 수 있다.

8. Translation and Startup

C언어를 작성하면 컴파일러는 C코드를 어셈블리 코드로 바꿔주게 된다.
어셈블러는 다시 기계어로 만들어 준다.
대부분 컴파일러는 이 2가지 step을 일괄적으로 처리한다.

이 프로그램에서 사용된 라이브러리와 새로 코딩한 프로그램을 합쳐서 실행파일을 만들어주는 linker가 존재한다.
실행 파일이 만들어진 다음에는 프로그램을 실행해야한다.(저장장치 - 메모리로 옮김)
이것을 loader가 담당한다.
loader는 프로그램을 메모리에 올려준다.

linker time에 object code가 실행파일로 들어오는 것을 Static linking이라고 한다.
이거와 반대되는 개념이 Dynamic linking이다.

9. Assembler Pseudoinstructions

MIPS 어셈블러 같은 경우에는 Pseudoinstructions이 존재한다.

실제 MIPS에 명령은 없지만 어셈블러에서 사용할 수 있는 가짜 명령어다.
이런 경우 어셈블러가 해당되는 실제 MIPS명령어로 자동으로 바꿔주게 된다.

예를 들어 move와 같은 명령어가 있을 수 있다.

at은 MIPS에서 사용할 수 없지만 어셈블러에서만 사용할 수 있는 레지스터이다.

10. Producing an Object Module

어셈블러가 프로그램을 기계어로 변환시켜 준다.
기계어로 변환할 때 object 모듈은 아래 정보를 가지고 있다.

Header : object의 내용
Text segment : instruction
Static data segment : 전역 변수
Relocation info : 프로그램이 로딩 됐을때 그것과 관련된 절대적인 주소를 가지고 있음
Symbol table : global 변수와 함수
Debug info : 소스코드 정보

11. Linking Object Modules

위 object module을 묶어서 실제 실행파일을 만들어야 한다.

segment들을 합친다.
Label들을 해결해준다.
location-dependent한 정보를 위치에 맞춰주고 외부참조도 해결해준다.

relocating loader에 의해 고쳐질 수 있는 location dependencies는 그대로 둔다.
하지만 현재 우리가 사용하고 있는 컴퓨터는 가상 메모리를 사용하게 된다.

가상 메모리는 모든 프로그램이 같은 메모리 영역을 사용하기 때문에 location dependencies 정보는 필요 없다.
즉, 가상 메모리의 절대 주소값을 쓰면 되는 것이다.

12. Loading a Program

실행 파일을 디스크에서 메모리로 올려야 한다.
실행파일의 Header를 읽은 후 segment의 크기를 결정해야 한다.

이후 가상 메모리 주소를 만든 후 데이터를 메모리 공간에 올려준다.

그 다음 stack을 위한 argument를 설정하고 register를 초기화 한다.

마지막으로 시작 routine으로 jump한다.
C언어 같은 경우는 main으로 jump하게 되는 것이다.
프로그램이 끝나게 되면 exit 시스템콜을 실행한다.

13. Dynamic Linking

Dynamic Linking은 해당 함수가 불려진 경우에만 link와 load를 하는 것이다.
static linking은 함수가 불려지든 안불려지든 실행파일에 집어 넣게된다.
하지만 dynamic은 오직 함수가 사용될때만 link와 load한다.

procedure code가 relocatable되도록 작성해야 한다.

static linking에 비해 Dynamic Linking을 많이 사용하는 이유는
실제 실행되는 것만 사용하기 때문에 실행파일의 크기가 커지는 것을 방지할 수 있다.

또한 Dynamic Linking은 그 함수에 관련된 코드가 실행파일에 들어가 있는 것이 아닌
Dynamic Linking이 저장되어있는 파일에 별도로 저장되어있다.

새로운 라이브러리가 나올때마다 그 파일만 업데이트 하면되므로 프로그램을 컴파일 할 필요가 없다.

라이브러리를 배포 및 사용할때 Dynamic Linking이 되는 라이브러리를 많이 사용하게 된다.
static linking보다 효율적이다.

14. Lazy Linkage

하지만 Dynamic Linking은 처음 Dynamic Linking이 되는 함수를 사용하면
위와 같이 복잡한 과정을 거치게 된다.

기존 함수는 타겟이 있는 코드로 바로 가지만 Dynamic Linking같은 경우에는
어떤 data에 가게되고 data에는 Dynamic Linking과 관련된 위치정보가 있다.
이 위치 정보를 사용해서 해당 코드가 있는 곳으로 가게된다.

그리고 그 코드에서 실제로 함수가 있는 코드로 Jump하게 된다.
그리고 해당 코드의 실행이 끝나면 다시 처음으로 돌아간다.
그림의 예시에서 실제 DLL Dynamic Linking으로 정의된 함수는 위 과정에서 마지막 코드에 있는 것이다.

물론 한번 불려지게 되면 이후에는 data에 위치에 DLL 시작주소를 바로 저장해서
위 과정을 거치지 않고 바로 실행하게 된다.

Static linking은 위 과정을 거치지 않는다.

우리가 함수를 정의하면 모든 함수가 항상 불려지지 않고 Data에 의존적으로 불려지게 된다.
그러므로 불려지지 않는 함수까지 위 과정을 미리 거치는 것은 불필요하게 된다.

그래서 불려지는 함수에 대해서만 위 과정을 거치는 것이다.
물론 위 과정들을 거치기 때문에 Dynamic Linking으로 구성된 함수를 사용하면 성능은 떨어지게 된다.
그러나 실행파일의 크기가 커지지 않고 새로운 라이브러리를 사용하더라도
실행파일을 다시 컴파일 하지 않는 장점이 있기 때문에
라이브러리 같은 경우에는 Dynamic Linking으로 정의돼서 많이 사용된다.

7. Instructions: Language of the Computer 3

eeminsu — Sun, 11 Apr 2021 21:44:35 +0900

KOCW 최규상 교수님 컴퓨터구조 강의 정리
이 글은 공부한 것을 복습 및 기록하기 위한 게시물입니다.
잘못된 정보가 기입되어 있을 수 있으니 주의해주시기 바랍니다.

참고 : 컴퓨터 구조 및 설계 - David A. Patterson,John L. Hennessy
강의 링크 : http://www.kocw.net/home/cview.do?lid=f64448266743ced9

1. Six steps in Execution of a procedure(Procedure Calling)

procedure 실행의 6단계를 뜻한다.

caller는 어떠한 함수를 부르는 것이고 callee는 불리여지는 함수를 뜻한다.
claller는 callee가 엑세스 할 수 있는 곳에 argument를 가져다 놓게 된다.
MIPS의 argument register는 $a0~$a3가 있다.
caller는 callee로 프로그램의 control을 넘기게 된다.
callee는 필요한 메모리 공간을 할당 받게 된다.
callee가 해야될 일을 하게 된다.
callee가 일을 다한 후에는 caller가 엑세스할 수 있는 위치에 return value를 저장하게 된다.
MIPS에서는 return value로 $v0, $v1이 있으며 callee가 해당 register를 통해 caller로 return value를 전달하게 된다.
callee가 다시 caller에게 프로그램의 control을 넘기게 된다.
이 때 retrun address를 알고 있어야 한다.
return address는 $ra register에 저장되어 있다.
이 값을 통해 caller로 프로그램 control이 넘어가게 된다.

2. Register Usage

MIPS에서 제공되는 레지스터이다.

3. Procedure Call Instructions

Procedure Call관련 명령어이다.

jal ProcedureLabel
이 명령어는 2가지를 동시에 하게 된다.

jal 다음 명령어의 주소를 ra에 넣음
해당 ProcedureLabel의 target address로 점프 하게 됨

그 다음 callee로 갔으니 caller로 가야한다.

jr $ra

$ra register에 들어있는 값으로 프로그램 control이 바뀌게 된다.
$ra에 값을 Program Counter에 저장하게 되며 $ra에 있는 값으로 점프하게 되는 것이다.

3-1. Leaf Procedure Example

Leaf Procedure는 해당 함수에서 다른 함수를 부르지 않는 것을 뜻한다.
해당 C코드를 MIPS코드로 컴파일 하게 되면 아래와 같다.

addi $sp, $sp, -4 (allocation)
스택 포인터를 4만큼 감소시킨다.
스택은 위에서 부터 아래로 감소하게 된다.
-4를 한다는 것은 4byte만큼 스택에 할당한다는 뜻이다.
sw $s0, 0($sp)
할당 된 공간에 기존에 $s0 값이 어떤 값이 저장되있을 수도 있으니 $s0 레지스터를 스택에 저장해 놓는다.
그리고 이 $s0를 f변수로 사용한다.
add $t0, $a0, $a1
그 다음 $a0와 $a1을 더한 후 $t0에 넣는다.
add $t1, $a2, $a3
그리고 $a2와 $a3을 더해서 $t1에 넣는다.
sub $s0, $t0, $t1
그리고 나서 $t1과 $t0를 뺀 후 $s0에 넣는다.
add $v0, $s0, $zero
연산된 결과 값($s0)을 zero와 더한 후 $v0에 넣는다.
move 명령어와 같은 역할을 하게 된다.
lw $s0, 0($sp)
스택에 있는 값을 다시 $s0에 넣는다.
$s0를 로컬 변수로 사용했으며 다 사용한 후에는 원래 값으로 복원시켜 놓아야 한다.
addi $sp, $sp, 4 (deallocation)
그 다음 4byte만큼 할당받은 메모리를 반납해야한다.
jr $ra
마지막으로 $ra에있는 레지스터 값으로 점프하게 된다.

caller가 jal leaf_example라는 명령어를 실행한다.
이 순간에 jal 명령어 다음에 오는 명령어 주소가 $ra에 들어가게 된다.
그 다음 leaf_example를 다 실행한 후 $ra에 있는 주소로 점프하게 되는 것이다.
즉, jal leaf_example 다음 명령어가 실행 되는 것이다.

3-2. Non-Leaf Procedures

Leaf Procedures는 그 함수에서 다른 함수를 호출하지 않아 함수를 처리하는데 아주 수훨하다.

하지만 하나의 함수가 또 다른 함수를 부를 수 있다.
이런 경우는 처리가 복잡해진다.
caller가 그 안에서 다른 것을 부르게 되면 $ra레지스터 값을 다른 곳에 저장해두어야 한다.
또한 arguments나 temporaries 등 또한 스택에 저장해두어야 한다.
그 다음 callee에서 caller로 온 후 스택에 저장된 값을 복원해야 한다.

Non-Leaf Procedures는 Leaf Procedures보다 처리가 복잡하다.

3-2-1. Non-Leaf Procedure Example

C코드는 Leaf Procedure와 비슷하지만 어셈블리 코드는 매우 복잡하다.
MIPS 코드로 컴파일 한것은 아래와 같다.

*fact:
addi $sp, $sp, -8
sw $ra, 4($sp)
sw $a0, 0($sp)
스택을 -8을 하게 된다.
2가지 값을 저장하기 위해서이다.
바로 retrun address와 argument이다.
slti $t0, $a0, 1
$a0와 1을 비교한다.
$a0가 1보다 작으면 $t0가 1이 된다.
만약 $a0가 1보다 크다면 $t0는 0이 된다.
beq $t0, $zero, L1
$t0와 zero가 같으면 L1 label로 점프하게 된다.
그러나 $t0가 zero와 같지 않다면 그 다음 명령어로 점프하게 된다.
addi $v0, $zero, 1
$a0가 1보다 작다면 $t0가 0이 되어서 $t0와 zero가 같아지고 해당 명령어를 실행하게 된다.
1을 $v0에 넣게 된다.
addi $sp, $sp, 8
스택 값을 다시 8만큼 증가한다.
할당 받은 것을 deallocation하기 위함이다.
jr $ra
그다음 $ra의 있는 값으로 점프하게 된다.
만약 L1 label을 실행했다면 lw $a0, 0($sp) 명령어를 실행하게 되는 것이다.
L1 :
addi $a0, $a0, -1
만약 $a0의 값이 2라고 가정하면 해당 명령어를 실행하게 된다.
$a0의 값을 1만큼 감소한다.
그리고 그 다음 명령어를 실행한다.
jal fact
fact label로 점프한다.
해당 명령어를 실행할 때 이 명령어의 다음 명령어가 있는 메모리 주소 값이 $ra register로 들어가게 된다.
lw $a0, 0($sp)
lw $ra, 4($sp)
addi $sp, $sp, 8
mul $v0, $a0, $v0
jr $ra
해당 fact label을 부른 caller로 가게 된다.

4. Local Data on the Stack

실제 프로그램에서 함수를 사용할 때 메모리가 어떤 식으로 할당 되는지 보여주는 그림이다.

frame pointer와 stack pointer가 있다.

stack pointer는 현재 스택에 있는 top의 위치를 가리키는 포인터이다.(register)

하나의 함수를 실행할 때 할당되는 메모리 공간을 activation record라고 부른다.
activation record의 처음 시작하는 위치를 가리키는 것을 frame pointer라 한다.

activation record의 시작을 가리키는 것을 frame pointer, 끝을 가리키는 것을 stack pointer라 한다.

activation record는 argument, return address, 필요한 register, 로컬 변수들이 저장 된다.

함수가 끝나게 되면 activation record는 deallocation이 된다.
그렇게 되면 frame pointer와 stack pointer는 조정이 된다.
다시 바로 위에 activation record 관련 시작 주소와 끝 주소를 가리키게 된다.

5. Memory Layout

실제 우리가 사용하는 메모리는 그림과 같은 구조로 할당이 된다.

맨 아래 주소 공간은 예약 되어있다.
그 위에는 Text가 저장 된다.
Text는 명령어들이다.(프로그램 코드)

그리고 그 다음 전역변수인 static 변수가 저장된다.

메모리 제일 끝 공간을 stack이라고 한다.
이 공간에는 activation record들이 할당이 된다

그리고 동적데이터(malloc)가 할당되는 heep이 있다.
static data 위에 있게 된다.

stack은 아래 아래방향으로 할당되며 Danymic data는 위 방향으로 할당이 된다.

프로그램을 실행하다보면 stack overflow가 생길때가 있다.
이 경우는 stack이 계속 증가하여 heap공간을 침범하게 되면 stack overflow가 발생하게 되는 것이다.

Program Coutner값은 Text 안에서 움직이게 된다.
global pointer는 static data를 엑세스하기 쉽게 하기 위해서 사용되는 포인터로
Text가 할당이 되고 그 위를 가리키게 된다.

MIPS에서는 static data가 0x1000 ffff와 0x1000 0000사이에 할당된다.
global pointer는 해당 값의 중간 값을 갖게 된다.

6. Character Data

char은 byte이다.

처음에는 알파벳만 저장할 수 있도록 정의가 되었다.
하지만 아시아는 다양한 문자들이 있어서 Unicode라는 것이 제정이 된다.
유니코드는 32bit Character set이다.

ASCII, Latin-1은 문자를 무조건 8bit로 표현한다.
하지만 variable-length(UTF-8, UTF-16)는 여러 byte를 사용해서 표현할 수 있다.

7. Byte/Halfword Operations

1byte, 2byte데이터를 엑세스할 때가 있다.

lb는 1byte만큼 로딩하며 lbu는 unsigend로 로딩한다.
lb와 lbu는 byte 또는 2byte를 읽는다 하더라도 32bit로 extend를 해서 레지스터에 넣게 된다.

sb는 1byte만큼 store한다.
이런 경우 rightmost에 저장이 된다.
혹은 halfword에 저장이 된다.

7-1. String Copy Example

strcpy는 Leaf Procedure이다.

String에서 null이 존재하면 String은 끝이 나게 된다.
해당 C코드를 MIPS 코드로 컴파일하게 되면 아래와 같다.

addi $sp, $sp, -4
i 로컬 변수를 사용하기 위해 스택을 4만큼 감소시킨다.
sw $s0, 0($sp)
거기에 기존에 있던 $s0값을 저장한다.
L1 :
add $t1, $s0, $a1
그 다음 $s0에다가 $a1을 더하게 된다.
lbu $t2, 0($t1)
1byte만큼 읽는다.
즉, y[i] index 값을 $t2에 넣는 것이다.
add $t3, $s0, $a0
x[i]의 주소를 계산한다.
sb $t2, 0($t3)
y[i]의 값을 x[i]에 저장한다.
beq $t2, $zero, L2
y[i]가 0과 같은지 아닌지를 체크한다.
같다면 L2레이블로 점프하며
같지 않다면 다음 명령어를 실행한다.
addi $s0, $s0, 1
i 값을 1만큼 증가한다.
j L1
L1으로 점프한다.
점프는 무조건 실행하게 된다.
해당 라인은 loop에 해당된다.
L2 :
lw $s0, 0($sp)
기존에 $s0에 있던 값을 복원한다.
addi $sp, $sp, 4
스택값을 조정한다.
jr $ra
caller로 점프하게 된다.

6. Instructions: Language of the Computer 2

eeminsu — Sat, 10 Apr 2021 22:34:54 +0900

KOCW 최규상 교수님 컴퓨터구조 강의 정리
이 글은 공부한 것을 복습 및 기록하기 위한 게시물입니다.
잘못된 정보가 기입되어 있을 수 있으니 주의해주시기 바랍니다.

참고 : 컴퓨터 구조 및 설계 - David A. Patterson,John L. Hennessy
강의 링크 : http://www.kocw.net/home/cview.do?lid=4e4c594ab2a7a659

1. Unsigned Binary Integers

컴퓨터에서는 2진수를 사용한다.

n비트로 되어있는 숫자는 위와 같이 표현한다.
범위는 0 to +2ⁿ – 1 이다.

공식의 예로는 위와 같다.
0부터 4,294,967,295까지 표현이 가능하다.

2. 2s-Complement Signed Integers

n비트로 되어있는 숫자는 위와 같이 표현한다.

범위는 위와 같다.
항상 음수의 최대값이 양수의 최대값보다 하나 더 많다.

공식의 예로는 위와 같다.
–2,147,483,648부터 +2,147,483,647까지 표현이 가능하다.

2s-Complement Signed Integers를 읽을 때 항상 가장 왼쪽에 있는 LSB(31bit)는 Sign bit이다.
0이면 양수이고 1이면 음수이다.
음수의 최대 값은 LSB만 1이고 나머지는 모두 0이다.
양수의 최대 값은 LSB만 0이고 나머지는 모두 1이다.

3. Signed Negation

부호를 바꿔주는 것이다.
각 비트의 값을 반전 시켜주고 해당 값에 1을 더해주는 것이다.

4. Sign Extension

예를 들어 8bit를 16bit 혹은 32bit로 확장하는 것이다.
bit의 수를 확장할때도 음수는 그대로 유지되어야 한다.

sign bit를 왼쪽에서 부터 확장하면 되며 모든 값을 1로 채운다.
unsigned는 0으로 채우면 된다.

5. Representing Instructions

모든 명령어는 binary로 표현되며 이것을 기계어라고 한다.
MIPS 명령어는 32bit로 표현이 된다.
32bit 코드지만 MIPS명령어는 operation code의 수가 적다.
MIPS는 Format이 별로 없어 간단히 만들 수 있고 높은 성능을 얻을 수 있다.

6. MIPS R-format Instructions

Arithmetic Instruction이다.
32bit은 6개의 영역으로 구성되어있다.

op : Operation 코드이다.
rs : source register이다.
rt : target register이다.
rd : destination register이다.
shamt : shift amount이다.
funct : function code를 나타낸다.

6-1. R-format Example

add의 opcode는 0이다.
s1과 s2는 각각 source register와 target register로 가며 t0또한 destination register로 간다.
shift 연산이 아니기에 shift amount는 0이다.

해당 값들을 bin으로 바꾸면 00000010001100100100000000100000이 되며 16진수로는 0x02324020이다.
CPU는 해당 값의 명령어(0x02324020)를 만나면 add $t0, $s1, $s2을 실행한다.

7. Hexadecimal

컴퓨터에서 어떤 숫자를 표현할 때 사람들이 이해하기 쉽게하기 위해 16진수로 표현한다.
16진수는 4bit를 표현할 수 있다.

8. MIPS I-format Instructions

immeditate format Instructions이다.
4개의 영역으로 구성되어 있다.

Operation code
source register
target register
constant 또는 address

해당 format에 들어가는 명령어의 종류는 Immediate arithmetic 와 load/store instructions 이다.
target register는 destination register 일 수도 있고 source register가 될수도 있다.
constant는 해당 범위까지 표현할 수 있다.
address는 source register에서 더해지는 offset이다.

Design Principle 4: Good design demands good compromises

상이한 서로 다른 두개를 하나로 만드는 것이다.
Immediate arithmetic 와 load/store instructions은 각각 다른 instruction이지만
I-format Instructions으로 두개를 모두 사용할 수 있다.
이렇게 되면 Instruction의 복잡도가 낮아진다.
format이 단순해져서 훨씬 더 고성능을 얻을 수 있다.

9. Stored Program Computers

메모리에는 다양한 프로그램이 들어가며 명령어는 binary로 되어있다.
인스터럭션과 데이터는 메모리에 있다.
프로그램은 프로그램에 관련된 프로그램을 제공한다.

어떤 바이너리 코드가 다른 머신에서 실행될 수 있는지는 표준화된 ISA가 지원이 되면 가능하다.

10. Logical Operations

이런 bit연산은 한 word에서 특정한 bit의 값을 뽑아내거나 추가할 때 효과적으로 사용할 수 있다.

11. Shift Operations

R-format Instructions이다.
shamt는 shift를 몇번 할 것인지를 나타낸다.

Shift left logical은 bit를 왼쪽으로 shift하고 0으로 채우는 것이다,
i만큼 bit를 shift left를 하게 되면 2에 i로 제곱한 효과가 있다.

Shift right logical bit를 오른쪽으로 shift하고 0을 채우는 것이다.
i만큼 bit를 shift right를 하게 되면 2에 i로 나머지 연산을 한 효과가 있다.

12. AND Operations

특정한 bit의 값을 뽑아낼때 사용한다.

13. OR Operations

특정한 bit를 1로 설정할때 사용하기 좋다.

14. NOT Operations

bit를 모두 반전시키는 것이다.

MIPS는 NOT Operations를 가지고 있지 않다.
대신 nor Operations을 사용하여 NOT Operations을 구현한다.(nor $t0, $t1, $zero)

15. Conditional Operations

C언어로 보면 조건문과 같다.

beq rs, rt, L1은 rs와 rt의 값이 같으면 L1으로 가는 것이고 같지 않으면 다음 명령어를 실행한다.
bne rs, rt, L1은 rs와 rt의 값이 같지 않으면 L1으로 가는 것이다. 같으면 다음 명령어를 실행한다.
j L1은 무조건 L1으로 가는 것이다.

15-1. Compiling If Statements

f, g, h, i, j가 $s0, $s1, $s2, $s3일때 컴파일 된 MIPS 코드를 봐보자

bne $s3, $s4, Else i와 j가 같으면 다음 명령어(add $s0, $s1, $s2)를 실행하고
그렇지 않다면 Else(sub $s0, $s1, $s2)를 실행한다.
만약 값이 같다고 했을 때 g와 h를 더한 후 f에 값을 집어 놓고 Exit을 실행하게 된다.
만약 값이 같지 않을 경우 g와 h를 뺀 후 다음 명령어인 Exit을 실행하게 된다.

15-2. Compiling Loop Statements

while문에 대한 C코드를 MIPS로 컴파일 한 경우이다.

i를 2만큼 bit를 왼쪽으로 shift를 시킨 후 t1에 넣는다.(i가 1이라면 4가 된것), 즉 4를 곱한 것이다.
save가 integer 배열이라 1개의 element가 4byte이다.
그래서 index만큼 index에 4를 곱해준 다음 더해줘야 한다.

t1과 save 배열의 시작주소를 더해서 다시 t1에 넣는다.
그 다음 t1을 4byte(word)만큼 load해서 t0에 넣는다.
그리고 t0와 $s5(k)가 같지 않으면 Exit으로 가고 같다면 다음 명령어를 실행한다.
$s3(i)에 1을 더한 후 $s3(i)에 넣는다.
그리고 Loop로 다시 점프한다.

16. Basic Blocks

명령어들의 시퀀스이다.

Basic Blocks은 2가지 조건을 만족해야 한다.

중간에 branch 명령어가 없어야 한다.
중간에 branch target이 없어야 한다.(처음에는 있어도 된다.) - ex.(라벨되어 있는것 loop exit 등등)

compiler는 Basic Blocks을 찾아서 Basic Blocks을 빨리 실행하도록 하는 일을 한다.
프로세서 역시 Basic Blocks을 빨리 실행하게 한다.
compiler와 프로세서는 Basic Blocks을 높은 성능을 얻기 위해 최대한 빨리 실행해야한다.

17. More Conditional Operations

어떤 조건이 true이면 결과에 1을 세팅하고 그렇지 않으면 0을 세팅한다.

slt rd, rs, rt
rs가 rt보다 작으면 rd에 1을 저장하는 것이고 그렇지 않다면 0을 저장하는 것이다.

slti rt, rs, constant
rs가 상수보다 작으면 rt는 1 아니면 0을 저장하는 것이다.

slt는 beq, bne와 같이 사용된다.

18. Branch Instruction Design

blt, bge, etc 이런것은 왜 지원해주지 않는가

H/W에서 어떤 값이 같은지 틀린지보다는 작거나 크거나 연산이 훨씬 복잡하다.
=, ≠을 연산하는 것보다 <, ≥을 연산하는 것이 더 오래 걸린다.

즉, 더 많은 시간이 필요하므로 더 느린 clock period를 사용해야 한다.
느린 clock period를 사용하면 모든 연산은 다 느려지게 된다.

그래서 beq, bne이 흔하게 사용되어 이것만 지원해주게 된다.

19. Signed vs. Unsigned

Unsigned 는 명령어 끝에 u를 붙여야줘야 한다.(sltu, sltui)

5. Instructions: Language of the Computer 1

eeminsu — Thu, 8 Apr 2021 22:32:46 +0900

KOCW 최규상 교수님 컴퓨터구조 강의 정리
이 글은 공부한 것을 복습 및 기록하기 위한 게시물입니다.
잘못된 정보가 기입되어 있을 수 있으니 주의해주시기 바랍니다.

참고 : 컴퓨터 구조 및 설계 - David A. Patterson,John L. Hennessy
강의 링크 : http://www.kocw.net/home/cview.do?lid=bae6f412d7ecafe8

1. Instruction Set

Instruction Set은 컴퓨터에서 사용되는 instruction의 집합이다.
다른 컴퓨터들은 각기 다른 Instruction Set을 가지게 된다.
하지만 대부분의 경우 공통된 특성을 가지고 있다.

초창기 컴퓨터들은 매우 단순한 Instruction Set을 가지고 있었으며 Instruction Set의 종류가 적었다.
최근 CPU들 또한 단순한 Instruction Set을 가지게 된다.
물론 초창기와 최근 사이에 complex instruction set을 가지는 CPU들이 존재했었다.

단순 - 복잡 - 단순의 과정을 거친 것이다.

1-1. Instruction Set Architecture(ISA)

ISA는 H/W와 가장 낮은 레벨의 S/W(ex.시스템 소프트웨어or 운영체제임)간에 인터페이스이다.
이런 ISA를 사용하여 필요한 정보들을 machine에 주는 것이다.
즉 필요한 정보를 Instruction에 담아서 H/W(CPU)에 주면 H/W는 그 Instruction을 실행한다.

ISA를 사용하면 똑같은 소프트웨어를 실행할 때 성능과 비용에 따라 다른 implementation이 가능하게 된다.
즉, ISA만 같다면 같은 소프트웨어를 여러개의 CPU에서 실행할 수 있다는 것이다.

1-2. Application binary interface(ABI)

ABI는 ISA와 O/S의 combination을 칭한다.
ABI는 유저관점에서 아주 중요하다.
ABI가 같다는 것은 어떤 프로그램이 특정 PC에서 실행될 때 그 프로그램은
다른 컴퓨터에서 ABI가 같으면 해당 컴퓨터에서도 실행할 수 있다.

예를 들어 집에서 PC를 사용할 때 MS Word를 사용한다고 하면 , 다른 환경에서도 MS Word를 실행할 수 있다.
그 이유는 두개의 컴퓨터 ABI가 같기 때문이다.
같은 운영체제(윈도우)와 같은 CPU(인텔)를 사용하기 때문이다.

2. The MIPS Instruction Set

MIPS(Million Instructions Per Second)는 컴퓨터의 연산 속도를 나타내는 단위로도 쓰이지만 CPU의 이름이기도 하다.

MIPS는 RISC(축소 명령 집합 컴퓨터)의 구조 및 그 구조를 이용한 MCU를 뜻한다.
임베디드 시스템에서 많이 쓰이고 있으며 최근엔 ARM이 많이 쓰이고 있다.

MIPS에서 사용하는 대부분의 특성은 많은 CPU들에 의해서 공유되고 있다.

2-1. Arithmetic Operations(산술연산)

컴퓨터에서 많이 사용되는 Operations 중 하나인 Arithmetic Operations이다.

어셈블리 언어에서 add a, b, c를 하게 되면 b, c를 더해 a에 할당하게 된다.
모든 Arithmetic Operations은 이와 같은 형태를 갖게 됨

Design Principle 1: Simplicity favours regularity
CPU를 설계하는 첫번째 원칙이다.
규칙성을 주게 되면 구현할 때 수월하다.
간단하게 만들어야 낮은가격으로 높은 성능을 낼 수 있다.

C코드를 MIPS 코드로 컴파일하면 위와 같이 된다.
위 코드에서는 쉽게 이해할 수 있게 변수로 표현되어 있지만 실제로는 레지스터에서 수행되어야 한다.

2-2. Register Operands

Arithmetic Operations은 Register를 사용하게 된다.

MIPS는 32bit Register를 32개 가지고 있다.
32bit data를 'word'라고 칭한다.
자주 사용되는 데이터를 Register에 로딩해서 사용하게 된다.

어셈블리에서는 temporary 값을 사용하는 $t Register와
variables 저장하기 위한 $s Register를 사용하게 된다.

Design Principle 2: Smaller is faster
CPU를 설계하는 두번째 원칙이다.
작을 수록 빠르다는 뜻이다.
대부분의 경우에 해당된다.
메모리의 크기도 작을 수록 빠르다.
Register가 메인 메모리에 비해 훨씬 빠르다.(약 1000배)

위 예제 C 코드에서 g는 s1, h는 s2, i는 s3, j는 s4에 맵핑 되어있다.
MIPS 코드로 컴파일된 코드를 보게 되면 $s1과 $s2를 더해 $t0에 넣고
$s3와 $s4를 더해 $t1에 넣게 된다.
이후 $t0와 $t1을 뺀 다음 $s0에 넣게되며 s0는 f에 맵핑되어 있다.

2-3. byte addresses

대부분의 컴퓨터에서는 메모리를 byte단위로 지정할 수 있게 된다.

alignment restriction(정렬제약)
대부분의 32bit 프로세서 같은 경우에는 memory address는 word단위로 맞춰진다,
기본 엑세스단위가 32bit이기 때문이다.

Endian은 데이터를 word에 어떤 방식으로 저장할 것이냐를 뜻한다.
Big endian은 leftmost byte로 큰 단위가 앞에 나온다.
Little endian은 rightmost byte로 작은 단위가 앞에 나온다.

대부분의 CPU는 1개의 endian만 지원함
최근 나온 ARM 프로세서는 2개 중 1개를 설정하여 사용할 수 있다.

2-4. Memory Operands

메인 메모리는 데이터를 저장하는 공간으로 사용된다.
Arithmetic Operations에서 이런 데이터를 사용할 경우 메모리에서 레지스터로 데이터를 로딩해야하고
연산의 결과를 레지스터에서 메모리로 써야한다.

그러나 메모리는 byte단위로 엑세스한다.
따라서 각각의 메모리 address는 byte로 되어있다.

또한 word 단위로 정렬되어 있어 address는 4의 배수로 되어 있다.

즉, MIPS는 byte단위로 엑세스되며 word단위로 정렬되고 Big endian을 사용한다.

2-4-1. Memory Operand Example 1

해당 예제 C코드에서 g는 s1, h는 s2, A 배열은 s3부터 연속으로 맵핑되어 있다고 가정한다.

MIPS 컴파일 코드는 위와 같이 되어있다.
A배열에는 8개의 index가 있게 된다.
A[8]의 값을 가져오려면 A[0]로 부터 32byte 뒤에 있는 값을 가져오면 된다.
1개의 배열은 4byte다.
A의 배열은 8개의 index가 있다.
따라서 8개의 index에 4byte씩 곱하게 되면 32byte가 된다.
s3는 A배열의 시작주소이며 s3에 32를 더해야 한다.

load word는 메모리로 부터 데이터를 로딩하는 것이다.
메모리 주소가 필요하며 메모리 주소는 32(s3)으로 표현 된다.
이 값에 32를 더한 메모리 주소에 가서 1word(4byte)만큼 읽어 t0에 넣는 것이다.
t0에는 A[8]의 값이 들어가게 된다.

2-4-2. memory operands ex2

해당 예제 C코드에서 h는 s2, A배열은 s3부터 연속으로 맵핑되어 있다고 가정한다.

MIPS 컴파일 코드는 위와 같이 되어있다.
t0에 A[8]의 데이터를 로딩해온 후 값을 넣어준다.
그다음 s2와 t0를 더해 다시 t0에 넣는다.

store word는 t0에 있는 값을 해당 시작 주소(48($s3))에 저장하는 것이다.

2-5. Registers vs. Memory

Registers는 메모리보다 엑세스시간이 훨씬 빠르다.
MIPS 프로세서에서는 메모리 데이터를 Registers에 로딩을 해서
연산을 한 후 메모리에 저장하는 방식을 택한다.(load store architecture)

MIPS는 명령어가 직접적으로 메모리에 엑세스해서 메모리에 있는 데이터를 연산을 하지 못하고
항상 load라는 명령을 사용해서 메모리에서 데이터를 Registers에 올린 후 연산을 한 다음
다시 메모리에 저장하는 방식을 택하게 된다.

위와 같은 방식을 사용하면 load staore때문에 많은 명령어가 필요하게 된다.

컴파일러는 Registers를 잘사용해야 한다.
variables을 위한 Registers를 효율적으로 잘 사용하는 것이 매우 중요하다.
잘 활용할 수록 메모리를 엑세스하는 횟수가 줄어들게 된다.
Registers optimization(최적화)은 컴파일러, 컴퓨터 구조에서 매우 중요하다.

2-6 MIPS Register File

MIPS는 32개의 32bit 레지스터를 가지고 있으며
2개의 read포트와 1개의 write포트를 가지게 된다.

Register는 메모리보다 빠르다.
Register를 사용하면 컴파일러가 훨씬 수월하며 코드의 접적도가 높다.
메모리를 엑세스할 때 32bit필요하지만 레지스터는 5bit이 필요하기 때문이다.
즉, 코드의 길이가 짧아진다.
코드의 집적도가 높다면 똑같은 일을 할 때 코드가 적다는 것이다.

2-7. MIPS Register Convention

$zero는 하드웨어로 정해져있으며 항상 0을 가지고 Read만 가능하다.
$at은 어셈블러만 사용하도록 예약되어있다.
$a는 function call을 사용하는 araguments로 사용된다.
$v는 returned values를 쓰는데 사용된다.

2-8. Immediate Operands

산술연산에서 기존 add의 피연산자는 모두 Register였다.
그러나 immediate operands는 3개의 피연산자 중 1개가 상수값을 갖는 것이다.
상수 값에서 음수는 add에서 가능하지만 sub에서는 지원하지 않는다.

Design principle 3: Make the common case fast
CPU를 설계하는 세번째 원칙이다.
많이 발생되는 사항을 빨리 처리해야 한다.

프로그램을 하다 보면 아주 적은 값의 상수를 많이 사용한다.
immediate operands를 지원하면 상수값을 바로 사용할 수 있지만
immediate operands이 지원되지 않는다면 메모리에서 항상 로드해야 한다.
immediate operands는 load 인스트럭션을 줄여주며 Make the common case fast의 대표적인 예이다.

2-8-1. The Constant Zero

MIPS의 0번 Resister이다.
Read만 가능한 Resister로 항상 0을 갖게 된다.
Move Instruction을 구현할 때 사용 된다.(복사할 때)

4. Computer Avstractions and Technology 4

eeminsu — Sat, 3 Apr 2021 22:57:33 +0900

KOCW 최규상 교수님 컴퓨터구조 강의 정리
이 글은 공부한 것을 복습 및 기록하기 위한 게시물입니다.
잘못된 정보가 기입되어 있을 수 있으니 주의해주시기 바랍니다.

참고 : 컴퓨터 구조 및 설계 - David A. Patterson,John L. Hennessy
강의 링크 : http://www.kocw.net/home/cview.do?lid=0342b09d1a791dd8

1. Power Trends

wall은 파워와 메모리에서 사용하는 표현이다.
이 부분은 Powerwall에 대한 내용이다.

그래프롤 보게되면 2004년까지 clock rate는 급격히 증가하였으나 2004년 이후로는 정체되어 있다.
clock rate이 증가하면서 전력소모 또한 급격히 증가하게 되었다. 그러나 2004년 이후로 전력소모는 감소하게 된다.

이기간 동안 Power는 30배 증가하였고 전압은 5V에서 1V로 줄어들었으며 Frequency는 1000배 빨라졌다.
Frequency가 1000배 빨리진 것에 반해 전력소모는 30배밖에 증가하지 않았다.
왜냐하면 전압을 1v로 낮췄기 때문이다.

clock rate가 더 이상 증가하지 않은 이유는 전력 소모 때문이다.

2. reducing power

요즘 컴퓨터는 전력소모를 위해 많은 노력을 한다.
새로운 CPU를 설계한다고 할때 기존에 CPU보다 capacitive load를 85퍼센트 사용하고
전압과 Frequency를 15% 감소할 경우
공식을 이용해 계산하면 기존의 CPU보다 약 52퍼센트의 전력소모를 사용한다.

Powerwall
더 이상 전압을 1V이하로 낮추지 못함
전력을 더 이상 낮추지 못하기 때문에 발열을 줄이지 못함

clock rate을 향상시키지 못한 이유는 발열을 더이상 낮추지 못했기 때문이다.
그래서 나온 성능향상 방법이 Multi Core이다.

3.Uniprocessor Performance

이 그래프는 싱글코어 프로세서의 퍼포먼스 그래프이다.

2004년을 기점으로 멀티코어가 나오게 된다.
싱글코어에서는 매년 52퍼센트씩 성능이 향상되었지만
2004년을 기점으로 성능 향상이 매년 22퍼로 낮아지게 되었다.

Power, instruction level parallelism(명령어 수준 병렬성), Memory latency와 같은 제약조건으로
성능향상에 제한이 생기게 되었다.

4.Multiprocessors

2004년을 기점으로 싱글코어의 clock rate을 더 이상 증가시키지 못했기 때문에 CPU의 성능 향상을 못하게 되었다.
그래서 다른 방식으로 성능향상을 꾀하였다.
그것이 바로 1개의 칩안에 프로세서를 여러개 두게 되는 Multi-Core이다.

Multi-Core의 성능향상을 위해선 Parallel 프로그램을 사용해야 한다.
기존에 사용한 Siquential 프로그램을 사용하면 Multi-Core에서의 성능향상은 없게 된다.

instruction level parallelism은 H/W가 알아서 명령어를 동시에 실행시켜주는 것이기 때문에
프로그래머는 이런 것을 고려할 필요가 없으며
CPU가 알아서 여러개의 명령을 동시에 실행시켜서 성능향상을 가져오게 된다.

하지만 프로그래머가 Parallel 프로그램을 만들어야 한다.
1개의 일을 여러개로 나눴을 경우 여러개의 일이 비슷한 Load를 가져야 한다.
그리고 communication과 synchronization의 overhead를 줄여줘야 한다.
이것은 아주 어려운 작업이다.

그래서 멀티코어에서의 성능향상은 기존 싱글코어보다 향상 폭이 낮아질 수 밖에 없어지는 것이다.

5. SPEC

5-1. SPEC CPU Benchmark

SPEC은 CPU, I/O, Web 등의 성능을 측정해주는 벤치마크를 만들어주는 회사이다.
그중 CPU에 관련된 벤치마크를 SPEC CPU Benchmark라고 한다.
이것을 통해 CPU 성능을 측정하게 된다.

5-2. CINT2006 for Intel Core i7 920

인텔 i7 920의 SPEC 벤치마크이다.
해당 CPU의 geometric mean의 spec ratio는 25.7이다.
즉 reference machine에 비해 25.7배 빠르다는 뜻이다.
해당 값이 클수록 성능이 좋은 것이다.

5-3. SPEC Power Benchmark

SPEC은 전력소모에 관련한 벤치마크 또한 만들었다.
Power 벤치마크의 단위는 ssj_ops per watt이다
Watt당 Server Side Java의 오퍼레이션의 수이다.

5-4. SPECpower_ssj2008 for Xeon X5650

인텔의 Xeon X5650 Power를 측정한 것이다.
해당 SPEC 벤치마크 결과는 2490이 되게 된다.
따라서 해당 값이 클수록 Watt당 많은 오퍼레이션을 수행한 것으로 전력효율이 좋은 것을 나타낸다.

6. Pitfall: Amdahl’s Law

컴퓨터의 어느 한 부분을 성능향상 시키면 전체 퍼포먼스의 성능향상은 그것에 비례하게 된다.
시스템의 한 Component의 성능을 향상하면 전체 시스템의 성능 향상은
그 Component가 시스템의 얼마나 비중을 차지하는지에 따라 비례해서 전체시스템의 성능이 향상되는 것이다.

예를 들어 곱하기 연산은 전체연산이 100초일 경우 80초를 차지하게 된다.
이럴 경우 곱셈 연산 성능을 향상시켜 전체 성능을 5배 향상시키려면 곱셈 연산을 얼마나 향상시켜야 하는가?
공식에 대입하여 보면 n은 무한대로 향해야만 성능향상이 된다. 즉, 해당 질문은 불가능 하다는 얘기다.
곱셈 연산의 성능 향상만으로는 전체 성능을 5배 향상시키는 것은 불가능하다는 것이다.

corollary : 어떤 시스템의 성능향상을 하고자 하면 그 시스템에서 가장많은 비중을 차지하는 컴포넌트를 빠르게 만드는 것이그 시스템의 많은 성능향상을 가져오게 되는 것이다.

7. Fallacy: Low Power at Idle

idle일때의 전력소모에 관련한 것이다.

위에 나온 i7에 벤치마크를 보게되면
100%사용할 때는 258W, 50% 사용할 때는 170W를 사용하게 된다.
그러나 10%만 사용해도 121W를 사용하게 된다.

CPU는 10%만큼 사용하지 않아도 전력소모는 47%만큼 사용하게 되는 것이다.
CPU LOAD와 전력소모는 비례하지 않는다.

구글의 데이터센터를 예를 들었을 때
데이터 센터는 10~50% load만큼 사용하게 된다.
100%를 사용하는 것은 전체 사용시간에 1%도 되지 않는다.
그러나 load가 낮더라도 전력소모는 아주 많다.

따라서 프로세서를 만들때는 load에 비례되도록 전력소모를 만드는 것이 필요하게 된다.
그래서 이부분은 컴퓨터 아키텍트들의 큰 숙제이다.

8. Pitfall: MIPS as a Performance Metric

MIPS는 시간당 몇 백만개의 instruction을 실행하는 가를 나타내는 것이다.
MIPS를 성능의 단위로 쓴적이 있다.
그러나 MIPS는 많은 오해를 가져올 수 있다.

이유는 다음과 같다.

컴퓨터 마다 ISA가 다름
명령어 마다 필요한 CPI 값이 모두 다를 수 있음

MIPS 는 CPI에 의해 좌우된다.
하지만 CPI는 CPU와 프로그램에 의해 달라질 수 있게 된다.
그래서 정확한 성능측정단위가 되기 어렵게 되는 것이다.

SPEC CPU 벤치마크 프로그램을 사용하는 것이 더 정확하다고 볼 수 있다.

9. Concluding Remarks

3. Computer Avstractions and Technology 3

eeminsu — Wed, 31 Mar 2021 23:23:20 +0900

KOCW 최규상 교수님 컴퓨터구조 강의 정리
이 글은 공부한 것을 복습 및 기록하기 위한 게시물입니다.
잘못된 정보가 기입되어 있을 수 있으니 주의해주시기 바랍니다.

참고 : 컴퓨터 구조 및 설계 - David A. Patterson,John L. Hennessy
강의 링크 : http://www.kocw.net/home/cview.do?lid=8cc704c8dfcaf55b

1. CPU Time

CPU Time은 CPU에서 걸린 Cycle의 수와 하나의 Clock Cycle Time의 곱으로 표현할 수 있다.
이것을 통해 알 수 있는 것은 성능은 Clock Cycle의 수를 줄이면 향상이 된다는 것이다.
마찬가지로 Clock Rate를 증가시키면 CPU Time은 감소하게 되며 성능은 향상이 된다.

컴퓨터 아키텍트는 Clock Rate와 Clock Cycle에 민감할 수 밖에 없다.
Cycle의 수를 감소시키면 Clock Rate가 감소하거 반대로 Clock Rate를 증가시키면 Cycle의 수도 늘어날 수 있기 때문이다.
컴퓨터 아키텍트는 이 두가지를 잘 조절하여 성능을 향상시켜야 한다.

1-2. CPU Time Example

컴퓨터A는 2GHz Clock을 가지며 10초의 CPU Time을 가진다.
컴퓨터B를 설계할 때 컴퓨터A에서의 CPU Time 10초를 6초로 줄이려 한다.
그리고 1.2배 빠른 Clock Cycle을 사용하려 한다.
이런 경우의 컴퓨터B의 Clock Rate는 몇이여야 하는가?

위 공식을 따라 계산을 하게 되면 Clock Rate는 4GHz가 필요하게 된다.

2. Instruction count and CPI

Clock Cycle은 Instruction의 수와 Instruction당 Cycle의 수(CPI) 곱으로 결정이 된다.
CPU Time은 Instruction과 CPI와 Clock Cycle Time 곱으로 결정이 된다.
또한 Instruction과 CPI의 곱을 Clcock Rate로 나눈 값으로 결정이 될 수 있다.

Instruction의 수는 프로그램, ISA, 컴파일러에 의해 결정이 된다.
CPI는 CPU H/W에 따라 결정이 된다.
또한 Instruction의 종류가 다를 경우 각각의 다른 Instruction은 서로 다른 CPI를 요구한다.
Instruction이 혼합되어 있는 경우에는 Average CPI를 사용해야 한다.

2-1. CPI Example

컴퓨터 A의 Cycle Time이 250ps 일때(4GHz Clock Rate) CPI는 2.0이다.
컴퓨터 B의 Cycle Time이 500ps 일때(2GHz Clock Rate) CPI는 1.2이다.
이 두 컴퓨터는 같은 ISA를 사용한다.(Instruction의 수가 동일함)

이 경우 두개의 컴퓨터중 어느것이 더 빠른가?
공식에 따라 계산을 해보면 컴퓨터A가 컴퓨터B보다 CPU time이 1.2배 빠르다는 것을 알 수 있다.

2-2. CPI in More Detail

다른 Instruction Class들은 다른 Cycle의 수를 요구하게 된다.
여러 개의 Instruction Class를 사용할 경우에는 Average CPI를 사용해야 한다.

2-3. CPI Example 2

sequence1과 sequence2라는 2가지의 컴파일 코드가 있다.

sequence1의 Instruction의 수는 5개이며 sequence2의 Instruction의 수는 6개로
sequence2가 sequence1보다 Instruction이 1개 더 많게 된다.

Clock Cycle은 각 Class의 수와 CPI를 곱하면 된다.
sequence1의 Clock Cycle은 10, sequence2의 Clock Cycle은 9가 된다.
Average CPI는 전체 Clock Cycle를 Instruction의 수로 나눠주면 된다.

sequence1의 Average CPI는 2.0, sequence2의 Average CPI는 1.5가 된다.

sequence2의 Instruction의 수는 sequence1보다 1개가 더 많았지만 실제로 걸린 Clock Cycle의 수는 1만큼 덜 걸리게 된다.
따라서 sequence2가 sequence1보다 더 빨리 실행될 수 있게 된다.
1개의 Instruction을 실행할 때 걸리는 CPI가 sequence1보다 짧기 때문이다.

3. Performance Summary

CPU Time을 보게 되면 Program은 Instruction으로 구성되어 있고 Instruction은 Clock Cycle로 구성되어있고
Clock Cycle은 Seconds로 구성되어 있다.

이것을 보고 알 수 있는 것은 아래와 같다.

Algorithm은 Instruction의 수에 영향을 주고 , CPI는 영향을 줄 수도 있다.
프로그램 언어는 Instruction의 수와 CPI 모두에게 영향을 준다.
컴파일러 또한 마찬가지로 Instruction의 수와 CPI 모두에게 영향을 준다.
ISA는 Instruction의 수와 CPI, Clock Cycle Time에 영향을 준다.

3-1. Example

Instruction의 종류는 총 4가지가 있다.

ALU
Load
Store
Branch

각 명령의 Freq는 각각 50, 20, 10, 20이며 CPI는 1, 5, 3, 2이다.
이럴 경우 Freq와 CPI를 곱하면 각각 0.5, 1.0, 0.3, 0.4가 된며 총합은 2.2이다.

Data Cache를 사용해서 Average load time을 2 cycles로 줄였을 때 기존에 비해서 CPU Time이 얼마나 향상되는가
Average loat time을 2 Cycles로 줄이면 Load는 0.4가 되며 총합은 1.6이 된다.
기존에 비해 37.5%만큼 향상이 되는 것이다.
Branch prediction을 사용해서 Branch Time을 1 Cycle 만큼 줄였을 때 CPU Time이 얼마나 향상되는가
Branch Time을 1 Cycle만큼 줄이게 되면 Branch의 Freq는 10%가 되며 CPI와 곱한 값은 0.2가 된다.
총합은 2.0으로 바뀌게 된다.
기존에 비해 10%만큼 향상이 되는 것이다.
2개의 ALU를 한꺼번에 실행할 경우 CPU Time이 얼마나 향상되는가
기존에 ALU의 CPI가 1이였는데 ALU 2개를 동시에 실행하면 CPI는 0.5가 된다.
그러므로 계산을 하게되면 총합은 1.95가 되며
기존에 비해 12.8% 향상이 되는 것이다.

2. Computer Avstractions and Technology 2

eeminsu — Mon, 29 Mar 2021 22:41:09 +0900

KOCW 최규상 교수님 컴퓨터구조 강의 정리
이 글은 공부한 것을 복습 및 기록하기 위한 게시물입니다.
잘못된 정보가 기입되어 있을 수 있으니 주의해주시기 바랍니다.

참고 : 컴퓨터 구조 및 설계 - David A. Patterson,John L. Hennessy
강의 링크 : http://www.kocw.net/home/cview.do?lid=83030621fe62e08e

1. Components of a Computer

많은 컴퓨터(데스크탑, 서버, 임베디드)에서 기본적으로 같은 구성요소를 가지고 있다.

User-interface Device
디스플레이, 키보드 마우스 등등
Storage Devcies
HDD, CD/DVD 등등
Network

스마트폰 혹은 태블릿PC에서는 터치스크린도 사용되고 있다.

LCD 스크린에서는 프레임 버퍼에 데이터를 쓰게 되면 화면에 해당 데이터들이 표시되게 된다.

2. Inside the Processor(CPU)

CPU는 3가지 구성요소가 있다.

Datapath : 연산들을 수행하기 위한 여러 유닛들의 구조
데이터가 어떤 operations을 해서 쭉 흘러가는지. 데이터가 어떻게 연산이 되는지
Control : 명령어를 해석하고 레지스터와 ALU 사이의 명령 흐름을 제어한다.
프로세스의 다양한 컴포넌트를 컨트롤 하게 된다.
캐시메모리 - 속도가 빠른 장치와 느린 장치 사이에서 속도 차에 따른 병목 현상을 줄이기 위한 범용 메모리를 말한다.
CPU 안에 아주 작고 빠른 SRAM을 가지고 있다
이런 SRAM으로 구성된 캐시메모리에 자주 사용되는 데이터를 올려놓아 빠르게 엑세스하게 된다.

애플의 A5 CPU이다.
데이타패스가 4개가 있으며
ARM 코어가 있다. 코어는 연산을 하는 곳이다.
하단에는 SRAM에 대한 인터페이스도 있있으며
I/O 인터페이스, USB 인터페이스 또한 있다.

3. Abstractions

아주 복잡한 문제를 풀 때 추상화 기법이 효과적이다.(단순화)
컴퓨터 구조에서는 ISA가 있다.
ISA는 명령어 집합 구조이다.
H/W S/W 인터페이스이며
S/W는 Instruction으로 구성되어 있고 H/W는 Instruction을 실행한다.
Instruction을 통해 데이터를 주고 받게 된다.

ABI는 단순히 말하면 ISA와 시스템 소프트웨어의 인터페이스이다.

Implementation은 ISA를 실제로 어떻게 구현할 것인지에 대한 내용을 말한다.

4. A Safe Place for Data, Networks

DRAM은 휘발성이다.
휘발성은 전원이 나가면 데이터들이 사라지게 된다.
저장장치는 비휘발성이다.(HDD, 플래시메모리, SSD)

네트워크는 LAN, WAN, WIFI, 블루투스 등이 있다.

5. Technology Trends

무어의 법칙과 관련이 있다.
X축은 시간(연도), Y축은 성능을 뜻한다.
시간에 따라 성능은 급격히 증가하게 된다.
예전에 비해서 DRAM을 아주 싼가격에 대량으로 사용할 수 있게 되었다.
표와 같이 시간이 지남에 따라 아주 급격히 성능이 향상되게 된다.

6. Semiconductor Technology

실제 칩을 만든다는 것은 실리콘에 기판을 새겨 넣는 것을 말한다.
Conductors, Insulators, Switch를 동작이 되도록 하는 것이다.

실리콘을 얇계 펴 Wafer를 만들고 가공단계를 거쳐 패턴을 입히게 된다.
패턴을 테스트하고 패키지를 만든다.(실제 칩을 만드는 것)
각각의 칩이 제대로 동작하는지를 체크하며 테스트가 완료되면 사용자에게 판매가 되는 것이다.

Yield란 수율을 뜻하며 Wafer당 동작하는 die의 비율을 뜻한다.
수율은 하나의 웨이퍼에서 칩이 몇개가 성공하는지 보는 것이다.

7. Performance

7-1. Defining Performance

비행기의 다양한 특성을 보여주는 그래프이다.

1번째 그래프(좌측 상단)는 한번에 태울수 있는 승객의 수를 나타내는 것이다.
2번째 그래프(우측 상단)는 한번에 얼마나 멀리 날 수 있는지를 나타내는 것이다.
3번째 그래프(좌측 하단)는 비행기의 속도를 나타내는 것이다.
4번째 그래프(우측 하단)는 한번에 태울수 있는 승객의 수와 속도를 곱한 것이다.

이중에서 어떤 비행기가 가장 좋은 성능을 가지고 있다고 볼 수 있을까?
성능의 기준을 승객수로 본다면 Boeing 747이 가장 좋고
기준을 거리로 본다면 Douglas DC-8-50이 가장 좋고
속력으로 본다면 BAC/Sud Concorde가 가장 좋다.

성능이란 어떻게 정의하느냐에 따라 달라지게 된다.

7-2. Response Time and Throughput

컴퓨터에서의 성능이란 무엇인가

Response time : task를 수행하는데 어느정도의 시간이 걸리는지
Throughput : 단위시간당 얼마나 많은 task를 수행할 수 있는지

다음 두가지 경우에 따라서 Response time과 Throughput은 어떠한 영향을 받는가

첫번째는 기존의 프로세서보다 더빠른 CPU를 사용할 경우 이다.
당연히 Response time과 Throughput 모두 영향을 받는다.
새로운 CPU를 사용하면 일을 더 빨리하게 된다.
따라서 Response time은 줄어들고 Throughput은 높아지게 된다.

두번째는 기존의 프로세서와 동일한 프로세서를 추가하는 것이다.
Response time은 변하지 않으나 Throughput은 높아지게 된다.
2개의 코어에서 각각 서로 다른일을 할 수 있기 때문에 단위시간당 하는일은 더 많아지게 되는 것이다.

일반적으로 Response time을 줄이면 Throughput은 같이 증가하게된다.
Response time은 Throughput에 영향을 주지만
Throughput은 Response time에 영향을 주지 않을 수 있다.

성능은 주로 Response time으로 표현할 수 있게 된다.

7-3. Relative Performance

Response time은 execution time(실행 시간)이라 할 수 있다.
execution time이 짧을수록 더 좋은 성능을 나타낸다.

'X는 Y보다 N배 빠르다'는 것은 execution time Y를 execution time X로 나눴을 때N이 나오면
X가 Y보다 n배 빠르다라고 할수 있는 것이다.

성능과 execution time은 반비례관계이다.

A는 10초가 걸리고 B는 15초가 걸린 다고 할때
이런 경우 execution time B / execution time A는 1.5가 된다.
이런 경우 A는 B보다 1.5배 빠르다라고 표현할 수 있다.

7-4. Measuring Execution Time

Elapsed time이란 Response time의 총합을 나타낸다.(오퍼레이션의 시작부터 끝까지 걸린 시간)
CPU 걸린 시간과 I/O에서 걸린 시간, 운영체제에서 걸린 시간을 모두 포함한다.
즉, 시스템 전체의 성능을 정의하게 된다.

CPU time은 어떤 일을 처리할 때 CPU에서 걸린 시간을 나타낸다.
I/O에서 걸린 시간과 CPU가 다른일을 할 때 시간을 제외하게 된다.

CPU time은 user CPU time과 System CPU time으로 나뉘게 된다.
user CPU time은 사용자가 사용할 때 시간을 나타내며
System CPU time은 운영체제가 사용할 때 시간을 나타낸다.

프로그램들은 CPU 또는 시스템 성능에 의해 서로 다르게 영향을 받을 수 있다.
어떤 프로그램은 CPU에 영향을 받을 수 있고 어떤것은 I/O의 영향을 받을 수 있는 것이다.

7-5. CPU Clocking

Rising Edge에서 다음 Rising Edge까지를 Clock period라고 하며 하나의 Clock Cycle이다.

단위는 시간의 단위를 쓴다.
Clock Frequency(rate)는 초당 몇 Clock Cycle이 존재하는지를 나타낸다.
Hz 단위를 사용하게 된다.

7-6. Machine Clock Rate

Clock Frequency는 Clock period와 반비례 관계이다.
Clock Cycle은 1/Clock Rate 이다.

1. Computer Avstractions and Technology 1

eeminsu — Sun, 28 Mar 2021 21:39:09 +0900

KOCW 최규상 교수님 컴퓨터구조 강의 정리
이 글은 공부한 것을 복습 및 기록하기 위한 게시물입니다.
잘못된 정보가 기입되어 있을 수 있으니 주의해주시기 바랍니다.

참고 : 컴퓨터 구조 및 설계 - David A. Patterson,John L. Hennessy
강의 링크 : http://www.kocw.net/home/cview.do?lid=c01867b2883af28c

1. The Computer Revolution

무어의 법칙에 의해서 컴퓨터기술은 급격하게 발전해왔다.
그로 인해 다양한 새로운 어플리케이션들이 가능해지게 되었다.

무어의 법칙은 1965년에 인텔 CEO인 Gordon Moore가 특정한 싱글 칩에 들어가는 트랜지스터의 수는
매년 2배씩 늘어날 것을 예언한 내용이다.
실제로는 2배보다 더 빠르게 증가하였다.
이렇게 많은 트랜지스터가 집적이 가능하기 때문에 다양한 새로운 어플리케이션들을 실행할 수 있게 되었다.

2. Classes of Computers

PC는 일반적인 용도로 사용되며 상당히 가격대 성능비에 민감하다.
Server Computer는 많은 회사에서 자신들의 회사에서 중요한 데이터를 처리하는데 사용된다.
보통 PC 보다는 고가, 대용량, 고성능이다.

아주 특수한 목적으로 복잡한 엔지니어링 문제를 푸는데 사용되는 슈퍼컴퓨터가 있다.
아주 고가이며 전력소모도 많고 유지비용도 많이 들게 된다.
우리나라에서는 기상청, 국방과학연구소등에서 운영하고 있다.

임베디드 컴퓨터는 큰 시스템에 컴퓨터가 하나의 요소로 구성되어있는 것을 뜻한다.
아주 적은 전력소모를 가지며 가격 또한 저가이다.
또한 유지비용이 적어 이에 해당되는 환경에서 대체로 많이 사용되게 된다.
가장 대표적인 예로는 스마트폰, 태블릿PC등이 있다.

컴퓨터에서 사용되는 기본적인 단위이다.

3. The PostPC Era

최근에 PC 트렌드이다.
스마트폰과 태블릿 PC가 일반 PC보다 많이 팔리고 있다.

Post PC 시대에는 PMD와 같은 것들이 많이 사용되게 된다.
보통 배터리로 동작하며 인터넷으로 연결되어 있다.

Cloud Computing은 특정한 데이터들을 처리해주는 하나의 서버에서 제공이 되는 것이다.
서버팜에서 필요한 서버 만큼을 할당해서 받게 된다.
필요한 소프트웨어를 서비스를 통해 제공받을 수 있다.
내가 사용하는 소프트웨어의 일부분은 PMD에서 실행되며 중요한 부분은 클라우드에서 실행된다.
즉, 복잡한 연산은 클라우드에서 실행되며 단순한 사용자 UI는 PMD에서 실행된다고 볼 수 있다.
대표적으로 아마존과 구글에서 클라우드 컴퓨팅 서비스를 해준다.

위와 같은 내용들을 해당 챕터에서 배우게 된다.

4. Understanding Performance

알고리즘
Operation의 수로 정의가 된다.
즉, 똑같은 2개의 알고리즘이 있을 경우 2개의 알고리즘 중 어떤것이 성능이 좋은가는 Operation의 수로 결정된다.
Operation의 수가 작을 수록 성능이 좋은 것이다.
프로그램 언어, 컴파일러, 아키텍쳐
인스트럭션의 수로 결정이 된다.
Operation은 좀 더 추상화된 개념이며 Instruction은 실제 CPU가 실행하는 명령어를 뜻한다.
프로세서와 메모리 시스템
얼마나 명령어를 빨리 실행할 것인지, 즉 단위시간당 얼마나 많은 명령어를 실행할 것인지로 결정이 된다.
I/O 시스템
I/O Operation의 수로 결정이 된다.
즉, 단위시간당 얼마나 많은 I/O Operation을 실행한 것인지로 결정이 된다.

5. Eight Great Ideas

컴퓨터 구조 분야에 대한 8가지 아이디어
컴퓨터의 성능향상에 지대한 공헌을 함

무어의 법칙
어떤 복잡한 문제를 단순화하기 위해 abstraction을 사용함
아주 많이 사용되는 일반적인 것을 빠르게 하는 것이 성능향상에 도움이 됨
Parallesim을 통해 Performance를 향상
Pipelining을 통해 Performance를 향상
예측을 통해 performance를 향상
메모리 계층
dependability via redundancy

6. Below Your Program

Application software(프로그램들)
일반적인 유저가 사용하는 소프트웨어이다.
예를 들어 MS오피스, 웹브라우저 등등이 있다.
System Software(윈도우 운영체제등등)
운영체제, 컴파일러와 같이 컴퓨터가 실행되는데 아주 기본적인 소프트웨어를 의미한다.
Compiler는 C/C++, JAVA와 같은 HLL로 작성된 code를 Machine code로 바꿔준다.
운영체제는 기본적으로 어플리케이션이 사용되는 서비스를 제공해준다.
I/O를 핸들링하거나 메모리, 스토리지를 관리해준다.
사용자 어플리케이션 태스크를 스케쥴링해주며 자원을 공유하여 준다.
Hardware(컴퓨터)
실제 만질수 있는 피지컬한 것이다.
프로세서, 메모리, I/O 컨트롤러등등

7. Levels of Program Code

High Level Language
C언어, JAVA와 같은 것이다.
컴파일러는 이러한 HLL을 Assembly language로 바꿔준다.
Assembly language
Machin instruction을 사람이 이해할 수 있도록 한 text적인 표현이다.
컴파일러에 의해서 생성이 된다.
이러한 Assembly language는 어셈블러를 통해 Machin code(binary)로 변환된다.
Hardware representation
binary digits로 연결되어 있다.
instruction과 data를 binary로 표현하게 된다.

Visaul Studio는 컴파일러와 어셈블러가 함께있는 것으로 보면된다.
나눠서 컴파일러만 실행할 수 있으며 어셈블러만 실행할 수도 있다.

무어의 법칙

무어의 법칙이란 매 2년마다 하나의 칩에 들어가는 트랜지스터의 수가 2배가 된다는 것을 뜻한다.

9. Process Synchronization 1

eeminsu — Sat, 20 Mar 2021 21:17:32 +0900

KOCW 반효경 교수님 운영체제 강의 정리
이 글은 공부한 것을 복습 및 기록하기 위한 게시물입니다.
잘못된 정보가 기입되어 있을 수 있으니 주의해주시기 바랍니다.
강의 링크 : http://www.kocw.net/home/cview.do?lid=aa53d6aa576466ee, http://www.kocw.net/home/cview.do?lid=5cf910642999f4a5

1. 데이터의 접근 - Race Condition

데이터를 Meomory에서 가져와 CPU에서 연산한 후 데이터의 결과를 Memory에 저장하게 된다.
이떠 CPU가 1개일 경우에는 문제가 발생하지만 Memory는 1개인 상황에서 CPU가 여러개일 경우 문제가 발생하게 된다.
이 문제를 Race Condition이라 한다.

Race Condition(경쟁 조건)은 둘 이상의 입력 또는 조작의 타이밍이나 순서 등이 결과 값에 영향을 줄 수 있는 상태를 뜻한다.

Race Condition은 멀티프로세서 뿐만 아니라 공유 메모리를 사용하는 프로세스들 간에서도 자주 발생한다.
또한 CPU가 1개이더라도 커널에서는 시스템 콜이 여러개가 오게될시 Race Condition이 발생하게 된다.

2. OS에서의 Race Condition

OS에서의 Race Condition이 발생하는 경우는 크게 3가지다.

Kernel 수행 중 Interrupt 발생 시
Process가 System call을 하여 Kernel mode로 수행 중인데 context switch가 일어나는 경우
Multiprocessor에서 Shared Memory 내의 kernel data

2-1. Kernel 수행 중 Interruppt 발생 시

위 예시에서 Kernel에서 Count 변수 값을 증가시키고 Interrupt handler가 Count 변수를 감소시켜 Count값이 변화가 없어 보이지만 실제로는 Interrupt handler의 결과 값이 반영되지 않게 된다.
왜냐하면 Kernel에서 이미 Interrupt handler가 들어오기 전에 Count 변수 값을 저장해놨다가 변수 값을 증가시키고 저장하기 때문이다.

그래서 해당 문제에 대한 해결 방법으로는 Kernel에서 특정 작업을 진행중일 때는 Interrpt를 disalbe 시킨 후 작업이 완료되면 Interrupt를 enalbe시켜주는 방법이 있다.

결국에는 처리 순서를 정해주면 해결되는 문제이다.
그러나 무작정 Interrupt를 막게 되면 CPU가 비효율적으로 돌아가는 일이 초래될 수 있다.

2-2. Process가 System call을 하여 Kernel mode로 수행 중인데 context switch가 일어나는 경우

이번 예제 또한 2-1과 마찬가지로 '프로세스A'가 Count 변수를 이미 Load 했기 때문에 '프로세스B'에서 작업한 Count++은 반영되지 않고 '프로세스A'에서의 Count++ 작업만 저장이 된다.

이러한 문제의 해결방법으로는 프로세스가 커널 모드에 있을 때 CPU 할당 시간이 끝나도 CPU를 박탈당하지 않게 하는 것이다.
이 방법을 사용할 시 CPU 할당시간이 제대로 지켜지지 않게될 수 있지만 RTOS가 아닌 시분할 동작이기 때문에 큰 문제가 발생하지는 않는다.

2-3. Multiprocessor에서 Shared Memory 내의 kernel data

이전 예제(2-1, 2-2)들은 CPU가 1개일 때 프로세스 혹은 커널이 뭔가를 작업하던 중 CPU 소유권이 넘어갔기 때문에 발생하는 문제이지만 이번 예제는 근본적으로 작업 주체인 CPU가 여럿일 경우에 발생하는 문제이다.

이번 문제의 해결방법은 2가지가 있다.

첫번째, 커널 전체를 lock을 해준 후 작업이 완료되어 커널을 빠져나올 때 unlock을 해주는 것이다. 즉, 한번에 하나의 CPU만 커널에 들어갈 수 있게 하는 것이다.
두번째, 커널 내부에 있는 각 공유데이터에 접근할 때마다 그 데이터에 대한 lock / unlock을 하는 방법이 있다.

당연히 1번 방법은 커널 전체를 lock하는 것으로 매우 비효율적이다.

3. 프로세스 동기화(Process Synchronization)문제

공유 데이터(Shared data)의 동시 접근(Concurrent access)은 데이터의 불일치 문제(inconsistency)를 발생시킬 수 있다.
일관성(Consistency) 유지를 위해서는 협력 프로세스(cooperating process)간의 실행 순서(orderly execution)를 정해주는 매커니즘이 필요하다.

Race Condition을 막기 위해서는 Concurrent process는 동기화(Synchronize)되어야 한다.

4. Critical-Section Problem

Critical Section이란 공유 데이터를 접근하는 코드를 의미한다.
만약 위 사진과 같이 P1에서 Critical Section이 실행 중일 때 CPU가 P2로 넘어가게 되면 P2의 Critical Section은 실행하지 않고 기다리고 있어야 한다.

4-1. Initial Attempts to Solve Problem

위 사진은 S/W로 코드를 넣어 Critical Section을 해결하는 방법이다.
프로세스는 공유 데이터에 접근하는 코드(Critical Section)와 공유 데이터에 접근하지 않는 코드(remainder section)로 반복되어 구성될 것이다.
공유 데이터를 접근하는 코드(Critical Section)이전에 entry section을 통해 일종의 lock을 걸어줄 것이며 exit section을 통해 unlock을 시켜줄 것이다.

5. 프로그램적 해결법의 충족 조건

프로그램적 해결법의 충족 조건은 3가지가 있다.

Mutual Exclusion - 배타적 접근
Progress - 둘이 동시에 들어가는 것을 막고자 하다보니 Critical Section에 아무도 있지 않은 상태에서 들어가지 못하는 상황이 발생할 수 도 있다.
Bounded Waition - Critical Section을 대기할 때 Starvation이 일어나지 않게 해야한다.만약 3개의 프로세스가 Critical Section을 사용하는데 2개의 프로세스만 서로 번갈아 가면서 사용하고 1개의 프로세스는 무한적으로 대기할 때 Bounded Waiting을 만족하지 못하는 상황이 발생하게 된다.

고급 언어의 문장들이 단일 Instruction이 아니기 떄문에 Critical Section 코드를 수행하는 도중에 CPU의 소유권을 빼앗겨서 발생하는 문제들이다.

5-1. Algorithm 1

turn 변수를 이용하여 프로세스의 순서를 정해준다.
turn이 자기 차례일 때는 Critical Section안으로 들어가고 나올 때 turn의 변수 값을 바꿔준다.
다른 프로세스는 turn이 자기 차례가 되지 않았을 때 While문이 돌아가고 있기 때문에 계속해서 대기를 하게 된다.

알고리즘 1은 충족 조건중 Mutual Exclusion은 만족하지만 Progress는 만족히자 못한다.
알고리즘 1은 무조건 한 프로세스가 Critical Section에 들어갔다 나와야 하는 교대형식의 코드이다.
프로세스들이 Critical Section에 들어가려는 빈도가 빈번하지 않을 수 있다.
만약 프로세스A는 Critical Section에 빈번하게 접근을 해야하는데 프로세스B는 그렇지 않다고 한다면 프로세스A는 Critical Section에 접근하지 못하는 상황이 발생하게 된다.

5-2. Algorithm 2

알고리즘 1의 문제를 보완하여 나온 것이 알고리즘 2이다.
flag 배열 변수를 사용한다.
자신의 flag 변수를 true로 만들어 주고 상대방의 flag 변수가 true이면 대기를 하게 되고 false이면 Critical Section에 접근하여 작업한 후 자신의 flag 변수를 false로 만들어 준다.

그러나 알고리즘 2 또한 문제가 있다.
프로세스A가 flag를 true로 바꾼 상태에서 프로세스B에게 CPU가 넘어가게 되면 프로세스B 또한 자신의 flag를 true로 바꾸게 된다. 이렇게 되면 두 프로세스 모두 Critical Section에 들어가지 못한 상태로 무한 대기를 하게 된다.
Progress를 만족하지 못한다.

5-3. Algorithm 3(Peterson's Algorithm)

알고리즘 3은 피터슨 알고리즘이다.
flag와 turn 변수를 둘다 사용하게 된다. 피터슨 알고리즘은 3가지 충족 조건을 모두 만족한다.

그러나 Busy Waiting(spin lock)문제가 발생할 수 있다.
프로세스A가 계속해서 Critical Section에 접근한 상태에서 프로세스B로 CPU가 할당이 된다면 프로세스B는 접근하지 못하고 계속해서 자신의 CPU 할당 시간 동안 무한대기를 하게 되어 효율적인 동작을 하지 못한다.

5-4. Synchronization Hardware

H/W적으로 Critical Section 문제는 쉽게 해결될 수 있따.
결국 Critical Section문제는 데이터를 메모리에서 읽는 것과 쓰는 것을 하나의 instruction으로 실행할 수 없기 때문에 발생하는 문제이다.

위 문제를 해결해줄 Instruction으로 Test_and_set(a)가 있다.
Test_and_set(a)은 a라는 값을 읽고 a를 1로 바꿔주는 것을 하나의 instruction으로 실행해주는 것이다.
Test_and_set(a)이 지원된다면 코드로 복잡하게 알고리즘을 구현할 필요가 없다.

8. CPU Scheduling

eeminsu — Sat, 20 Mar 2021 21:16:39 +0900

KOCW 반효경 교수님 운영체제 강의 정리
이 글은 공부한 것을 복습 및 기록하기 위한 게시물입니다.
잘못된 정보가 기입되어 있을 수 있으니 주의해주시기 바랍니다.
강의 링크 : http://www.kocw.net/home/cview.do?lid=aa53d6aa576466ee

5-5. Multilevel Queue

우선순위가 높을수록 위쪽에 위치하게 된다.
프로세스를 어느 우선순위에 배치시킬 것인지와 우선순위가 낮은 프로세스에 대한 Starvation 극복 방안을 고려해야 한다.

이러한 극복방안으로 Ready queue를 여러 개로 분할시킬 수 있다.
아래 방식은 queue가 2개인 방식이다.
foreground queue에는 interactive한 job을 대기시키고 background queue에는 batch형 job을 대기시킨다.

그리고 각 queue는 독립적인 Scheduling 알고리즘을 가져야 한다.
foreground queue는 interactive한 job들이 대기하고 있기 때문에 속도가 중요하므로 Round Robin을 채택하고
background queue는 CPU만 잡아먹는 batch형 job들이 대기하고 있기 때문에 FCFS을 채택할 수 있다.

그 다음 이제는 queue에 대한 Scheduling이 필요하다.
만약 우선순위를 강하게 적용하는 방식에서는 우선순위가 비어있지 않는 이상 아랫 순위에 CPU를 할당하기 어렵기 때문에
Starvation 현상을 겪을 수 있게 된다.

이러한 해결 방법으로 CPU time을 적절한 비율로 할당하여 주게 되면 Starvation은 발생하지 않게 된다.

5-6. Multilevel Feedback Queue

보통은 처음 들어온 프로세스는 우선순위가 높은 queue에 넣게 된다.
상위 queue일수록 time quantum은 짧게 된다.
할당시간이 최상위 queue에서 끝나게 되면 그 다음 하위 queue로 강등되게 된다.
최하위 queue는 FCFS를 사용하며 상위 queue들은 Round Robin을 사용하게 된다.
CPU 사용시간이 짧은 프로세스들에게 우선순위를 많이 주는 스케줄링 방식이다.

6. Multiple-Processor Scheduling

CPU가 여러개 일 경우 Load Sharing이 필요하다.
특정 CPU 1개만 일을 해서는 안된다.

7. Real-Time Scheduling

RTOS는 deadline이 보장되어야 하기 때문에 미리 Scheduling을 해놓게 된다.

8. Thread Scheduling

Local Scheduling : 운영체제가 CPU를 어떤 프로세스에게 할당할지만 결정하고 Thread의 경우는 프로세스 내부에서 알아서 Scheduling을 결정한다.
Global Scheduling : 운영체제가 Thread의 존재를 알고 있어 운영체제가 어떤 Thread에게 CPU를 할당할지 결정한다.

9. Algorithm Evaluation

Queueing models : 프로세스 도착율과 CPU의 처리율등을 통해 계산을 한다, 이론적으로 많이 사용하는 방식이다.
Implementation & Mesasurement : 실제 시스템에 구현하여 실제 작업에 대해 성능을 측정 비교한다, Queueing Models과 상반된다.
Simulation : Implementation & Mesasurement는 직접하기 어렵기 때문에 많이 사용되는 방법이다.

7. CPU Scheduling 1

eeminsu — Sun, 14 Mar 2021 21:06:02 +0900

KOCW 반효경 교수님 운영체제 강의 정리
이 글은 공부한 것을 복습 및 기록하기 위한 게시물입니다.
잘못된 정보가 기입되어 있을 수 있으니 주의해주시기 바랍니다.
강의 링크 : http://www.kocw.net/home/cview.do?lid=5488703b25305c37

1. CPU-burst Time

프로그램의 경로는 CPU만 연속적으로 사용하는 단계와 I/O를 사용하는 단계가 번갈아가면서 실행되는 것이다.
CPU에서 Instruction을 실행하는 단계를 CPU burst라고 하며 I/O를 쓰는 단계를 I/O burst라고 한다.
프로그램의 종류마다 CPU burst와 I/O burst가 나타나는 주기는 다르다.

I/O bound job이란 CPU를 짧게 사용하고 I/O burst가 자주 끼어드는 비중이 높은 것을 말한다.
CPU bound job이란 CPU를 오래 사용하고 I/O burst를 자주 사용하지 않는 것을 말한다.
실제로 CPU는 CPU bound job 비중이 높으며 I/O bound job은 빈도가 많지만 CPU를 사용하는 비중이 낮다.

CPU Scheduling이 필요한 이유는 I/O bound job 때문이다.
사람과 연결된 interative한 job을 우선순위로 두어야 한다.

CPU Scheduling은 2가지의 중요한 이슈가 있다.

누구에게 우선해서 CPU 소유권을 줄 것인가
언제 얼마만큼의 시간을 주고 뺐을 것인가

2. 프로세스의 특성 분류

3. CPU Scheduler & Dispatcher

CPU Scheduler는 누구에게 CPU를 줄 것인지 결정하는 운영체제(kernel) 코드이다.
Dispatcher는 CPU를 누구에게 줄지 결정되었으면 CPU를 전달해주는 역할을 하는 운영체제(kernel) 코드로
CPU에서 돌아가던 프로세스의 Context를 저장하고 새로 CPU를 넘겨주는 프로세스의 Context를 CPU 레지스터에 설정해놓는다.

CPU Scheduling이 필요한 경우는 다음과 같은 상태 변화가 있은 경우이다.

Running -> Blocked
nonpreemptive
ex) I/O를 요청하는 시스템 콜
Running -> Ready
preemtive
ex) CPU 소유권 할당시간 만료로 인한 timer Interrupt
Blocked -> Ready
preemtive
ex) I/O 완료 후 Interrupt
I/O가 끝났을 때는 Ready로 보내고 CPU를 바로 할당해주지는 않는다.
그러나 CPU를 바로 넘겨줄 때도 있다.
(ex. 우선순위 CPU Scheduling에서 I/O를 요청한 프로세스가 우선순위가 가장 높을 경우)
Terminate
nonpreemptive

nonpreemptive : 비선점형, 강제로 빼앗지 않고 자진 반납
preemptive : 선점형, 강제로 빼았음, 현대적인 CPU Scheduling

4. Scheduling Criteria

시스템 입장에서의 성능 척도 : 이용률, 처리량
프로그램 입장에서의 성능 척도 : 소요시간, 대기시간, 응답시간

CPU uillization(이용률)
전체시간에서 CPU가 일한 시간을 뜻한다.
가능한 CPU를 바쁘게 일을 시켜야 한다.
Throughput(처리량)
주어진 시간동안 몇 개의 작업을 완료하였는지를 뜻한다.
Turnaround time(소요시간)
CPU burst를 다 사용하고 나가는 시간을 뜻한다.
CPU burst에서 CPU를 쓴 시간과 기다리는 시간의 총합
Waiting time(대기시간)
CPU burst를 기다리는 시간을 뜻한다.
한번의 CPU burst안에서 CPU를 얻었다가 뺏겨서 기다리는 시간의 총합
Response time(응답시간)
처음으로 CPU를 얻기까지의 시간을 뜻한다.
CPU burst에서 처음으로 CPU를 얻기까지의 시간
time-sharing을 사용하는 환경에서는 처음으로 CPU를 얻는 시간은 사용자 응답과 관련하여 굉장히 중요한 시간이다.

preemptive Scheduling은 CPU를 얻었다고 해서 끝까지 사용할 수 있는 것은 아니다.
시간의 개념과 프로세스의 개수는 프로세스가 시작돼서 종료되는 것이 아닌 매 CPU burst건에 한해서
CPU Scheduling의 대상이 되는 것이다.

5. Scheduling Algorithms

5-1. FCFS(First-Come First-Served)

먼저 들어온 순서대로 처리하는 것을 말한다.
nonpreemptive Scheduling으로 효율성이 떨어진다.
맨 처음 어떤 프로세스가 선점하느냐에 따라서 대기시간이 천차만별이다.
긴 프로세스가 도착해서 짧은 프로세스들이 오래기다리는 것을 Convoy effect라고 한다.

5-2.SJF(Shortest-Job-First)

CPU를 짧게 쓰는 프로세스에게 먼저 CPU를 한당하는 것을 말한다.(CPU burst가 제일 짧은 것)
preemptive 기준으로 대기시간이 줄어들게 되고 제일 짧은 average 대기시간을 보장한다.
preemptive 버전은 SRTF라고도 부른다.

기존에 CPU를 사용하고 있는 프로세스보다 더 짧게 사용하는 프로세스가 들어올 때
CPU를 넘겨주는 것이기 때문에 기존에 CPU를 사용한 프로세스들 중에서도 제일 짧은 프로세스에게 CPU를 넘겨주게 된다.

SJF는 극단적으로 CPU 사용이 짧은 JOB을 선호하기 때문에 CPU 사용이 긴 프로세스는 영원히 CPU를 사용하지 못할 수 있다.
이러한 현상을 Starvation(기아) 현상이라 한다.
프로세스가 CPU 사용시간을 미리 알 수 없다.
과거의 데이터를 통해 사용시간을 예측할 수 있다.

1. 실제 CPU 사용시간.
1. CPU 사용시간을 예측한 시간

5-3. Priority Scheduling

우선순위 Scheduling을 뜻한다.
우선순위가 제일 높은 프로세스에게 CPU를 넘겨주게 된다.

이 Scheduling은 preemptive 버전과 nonpreemptive 버전으로 나눌 수 있다.

preemptvie : 현재 실행되고 있는 프로세스보다 우선순위가 더 높은 순위의 프로세스가 있다면 바로 CPU를 넘겨줌
nonpreemptive : 현재 실행되고 있는 프로세스는 다 실행할 동안 CPU를 보장해주고 완료가 되면 우선순위에 따라 CPU를 넘겨줌

우선순위가 높지않은 프로세스는 Starvation 현상을 겪을 수 있다.
이러한 해결법으로는 Aging(노화)이 있다.
Aging : 아무리 우선수위가 낮더라도 대기시간만큼 우선순위를 높여줌

5-4. Round Robin(RR)

현대적인 CPU Scheduling으로 preemptive Scheduling이다.
CPU 응답시간(response time)이 빨라진다.
대기시간이 CPU를 사용하려는 시간에 비례하게 된다.
할당시간이 길게 되면 FCFS와 같아지게 되고
할당시간이 짧게 되면 Context Switch overhead가 커지게 된다. 즉, 시스템 전체 성능이 낮아지게 된다.

CPU 사용시간이 모두 동일한 프로그램이 있을 때 FCFS는 적어도 1개의 프로세스만이라도 빨리 사용하고
나갈 수 있지만 Round Robin일 경우 동일한 대기시간을 가지고 동시에 프로세스가 나가게 된다.
이럴 경우 Round Robin 방식이 더 안좋을 수 있다.
그러나 일반적으로는 CPU 사용시간이 동일하지 않기 때문에 Round Robin이 효율적이다.
Round Robin은 Turnaround Time보다 Response Time이 짧아진다는 것에 장점이 있다.

6. Process Management

eeminsu — Sun, 7 Mar 2021 21:18:38 +0900

KOCW 반효경 교수님 운영체제 강의 정리
이 글은 공부한 것을 복습 및 기록하기 위한 게시물입니다.
잘못된 정보가 기입되어 있을 수 있으니 주의해주시기 바랍니다.
강의 링크 : http://www.kocw.net/home/cview.do?lid=b988d89cb0bc07b3, http://www.kocw.net/home/cview.do?lid=3a5437eaa6c9e5b0

1. 프로세스 생성

부모 프로세스 하나가 자식 프로세스를 여러 개 낳을 수 있으며 트리를 형성한다.
보통 부모 프로세스와 자식 프로세스 사이는 경쟁상대가 되기 때문에 자원을 공유하지 않는다.

부모 프로세스와 자식 프로세스가 주소 공간을 공유하지 않는 것이 원칙이지만
리눅스에서는 일단 주소 공간을 공유하게 되어있다.
PC(Program Counter)만 복사하여 똑같은 위치를 가르키게 된다.
그런 다음 자식 프로세스는 각자의 길을 가게 되면서 주소 공간을 복사하여 사용하게 된다.
이것을 Copy on Write(COW) 기법 이라고 한다.(Write가 발생했을 때 주소공간을 Copy)

프로세스의 생성은 부모 프로세스를 복제하여 프로그램을 덮어씌우는 단계로 수행되며
운영체제를 통해서만 프로세스 생성이 가능하다.
프로세스가 운영체제에게 자식을 낳아 달라고 부탁을 해서 운영체제가 대신 낳아주는 형태인 것이다.(fork() 시스템 콜)

fork() : 프로세스 복제
exec() : 새로운 프로그램을 덮어 씌움

2. 프로세스 종료

프로세스 종료는 2가지가 있다.

exit
프로세스 종료 시스템콜, 자식이 부모에게 output data를 보내는 자발적 종료
abort
강제적 종료

프로세스는 자식 프로세스가 먼저 종료된 후 부모 프로세스가 마지막으로 종료되어야 한다.

3. 프로세스와 관련한 시스템 콜

3-1. fork() 시스템 콜

예를 들어 위와 같은 C언어 코드가 있다.
부모 프로세스에서 pid = fork(); 줄이 실행되면 똑같은 자식 프로세스를 만들게 되고
부모 프로세스는 그 다음 코드를 실행하게 된다.

생성된 자식 프로세스는 int pid; 부터 실행되는 것이 아닌 pid = fork()부터 실행하게 된다.
왜냐하면 부모 프로세스의 Program Counter가 pid = for()를 가리킨 상태에서 복제하였기 때문이다.
그러나 자식 프로세스 또한 부모 프로세스와 동일한 코드를 가지고 있어 구분이 어렵게 된다.
이럴 경우에는 pid에 반환된 값을 통해 판단할 수 있다.
부모 프로세스는 양수를 반환받게 되며 자식 프로세스는 0을 반환받게 된다.

3-2. exec() 시스템 콜

exelp 명령어를 통해 exec() 시스템 콜을 실행할 수 있다.
위 코드에서는 자식 프로세스가 "/bin/date"라는 프로그램으로 덮어 씌어진것이다.
exec()을 사용하게 되면 다시 원 상태로 돌아올 수 없다.
꼭 자식 프로세스를 만들어서 exec()을 사용할 필요는 없기 때문에 fork()를 사용하지 않아도 된다.

3-3. wait() 시스템 콜

wait() 시스템 콜은 자식 프로세스가 종료될 때까지 기다리는 시스템 콜이다.(block 상태)
예를 들어 리눅스 쉘에서 프로그램 이름을 기입하고 엔터를 치면 해당 프로그램이 실행되며
쉘에는 프로그램이 종료될 때까지 아무것도 기입할 수가 없게 된다.
왜냐하면 쉘도 하나의 프로그램이기 때문이다.
쉘에서도 프로그램을 실행하면 그 프로그램은 일종의 자식 프로그램이며
쉘이 wait() 시스템 콜로 인해 block 상태가 되는 것이다.

3-4. exit() 시스템 콜

비자발적 종료 : 외부적인 요인으로 인한 종료

4. 프로세스간 협력(IPC)

프로세스간 협력 메커니즘(IPC)는 프로세스간 정보를 주고 받을 수 있는 방법을 뜻한다.
프로세스는 원칙적으로 독립적이기 때문에 메세지를 전달할 수 있는 방법이 없다.
그러나 kernel을 통해 메시지를 전달할 수 있다.

프로세스는 독립적인 주소공간을 갖기 때문에 자신의 주소공간만 볼 수 있다.
그러나 그럼에도 불구하고 shared memory는 서로 다른 프로세스가 일부 주소공간을 공유할 수 있다.

Thread는 CPU 수행 단위이기 때문에 하나의 프로세스의 주소공간을 공유하고 있으므로 협력이 쉽다.

4-1. Message Passing

Message Passing은 2가지 방법이 있다.

통신하려는 프로세스의 이름을 명시하는 여부에 따라 직접, 간접으로 나뉘게 된다.
2가지 방법 모두 kernel을 통해 전달하게 된다.

Direct Communication(직접)
특정 대상에게 메시지를 전달한다.
Indirect Communication(간접)
Mailbox에 메시지를 넣기 때문에 아무 대상에게 메시지를 전달한다.

4-2. Shared Memory

위 그림으로 예를 들어 프로세스A와 프로세스B는 주소공간이 서로 독립적으로 존재하지만
물리적인 메모리에 Mapping할 때 두 프로세스의 일부 영역을 공유되도록 Mapping을 시켜 놓는 것이다.

Shared Memory도 마찬가지로 Kernel에게 Shared Memory 관련 시스템 콜을 해서 메모리에 Mapping 해놓은 다음에
사용자 프로세스끼리 공유 영역을 사용할 수 있는 것이다.
Shared Memory는 프로세스간 신뢰가 높아야 한다.

5. Process 2~3

eeminsu — Sat, 6 Mar 2021 21:09:52 +0900

KOCW 반효경 교수님 운영체제 강의 정리
이 글은 공부한 것을 복습 및 기록하기 위한 게시물입니다.
잘못된 정보가 기입되어 있을 수 있으니 주의해주시기 바랍니다.
강의 링크 : http://www.kocw.net/home/cview.do?lid=29d9a718cff884c3, http://www.kocw.net/home/cview.do?lid=54e1a4abcd59272d

1. Thread

Thread란 CPU를 수행하는 단위를 뜻한다, 가벼운 Process라고 부르기도 한다.
Process 내부의 Thread가 여러개 있는 경우, Thread가 Process 내부에서 공유하는 것들을 task라고 칭한다.

동일한 일을 수행하는 Process가 여러 개 있을 경우 Process의 주소공간이 여러 개가 만들어지게 된다.
이러한 현상은 메모리를 낭비할 수 있다.
Thread는 Process 하나에서 공유할 수 있는 것은 최대한 공유하고 CPU 수행 관련 정보(PC, registers, stack)은 별도로 가지고 있게 된다.

예를 들어 네트워크를 통해 웹페이지를 불러올 때(이것 또한 I/O 작업) 다중 Thread 구조로 해놓으면
하나의 Thread가 웹서버에서 그림파일을 불러옴과 동시에 다른 Thread는 텍스트를 불러오게 된다.
이럴 경우 먼저 처리가 완료된 것 부터 표출되기 때문에 사용자는 기다리는 시간이 줄어들어 빠른 응답성을 제공받게 된다.
만약 웹페이지를 불러오는 것을 Thread가 아닌 Process 단위로 나누어 놓게 되면
동일한 일을 하게 되는데 메모리 낭비가 발생하게 된다.

CPU가 1개가 아닌 여러 개를 사용할 경우 Thread를 사용하면 병렬성을 높일 수 있다.
예를 들어 1000 x 1000 연산 작업을 수행할 때 행과 열을 곱하는 것을 Thread로 만들어 CPU가 각각 연산을 처리하고
더하게 되면 더 빠른 결과를 도출할 수 있다.

2. Benefits of Threads

Thread의 장점은 아래와 같다.

Resonsiveness(응답성)
ex) 웹 페이지를 불러올 때
Resource Sharing(자원 공유)
하나의 Process 안에서 Code, Data, Resource를 공유함
Economy(경제성)
Process 하나에 Thread를 추가하는 것은 Overhead가 크지 않으나 Process Context Switch는 Overhead가 높음
Utilization of MP Architecctures(멀티프로세서 아키텍쳐 활용)
Thread가 서로 다른 CPU에서 병렬적으로 일을 할 수 있음(병렬성)

3. Implementation of Threads

Thread의 구현 방식은 아래와 같다.

Kernel Threads
Thread가 여러 개 있다는 것을 Kernel이 알고 있는 것이다.
User Threads
Process 안에 Thread가 여러 개 있는 것을 Kernel은 모르고 사용자 프로그램이 스스로 라이브러리의 지원을 받아서
여러 개의 Thread를 관리한다. -> 구현 상의 제약이 있을 수 있다.

4. Process 1

eeminsu — Sat, 27 Feb 2021 21:22:07 +0900

KOCW 반효경 교수님 운영체제 강의 정리
이 글은 공부한 것을 복습 및 기록하기 위한 게시물입니다.
잘못된 정보가 기입되어 있을 수 있으니 주의해주시기 바랍니다.
강의 링크 : http://www.kocw.net/home/cview.do?lid=b31830a2b3cf1e60

1. 프로세스의 개념

프로세스란 실행중인 프로그램을 뜻한다.
프로세스 문맥(Context)은 프로세스의 현재 상태를 나타내는 모든 것을 뜻한다.
EX) PC(Program Counter)가 어디를 가리키는지, 프로세스가 메모리에 어떤 것을 담고있는지, 현재 변수의 값은 얼마이며 프로그램이 실행되면서 CPU의 레지스터의 어떠한 값을 넣어 놓고 어떤 Instruction까지 실행했는지 등등

프로세스의 문맥(Context)는 크게 3가지가 있다.

CPU 하드웨어 Context(주로 레지스터)
프로세스의 주소 공간(Code, Data, Stack)
OS(커널) 자료구조

프로세스들이 번갈아 가면서 실행되기 때문에 Context를 파악해놓는 것이 매우 중요하다.

2. 프로세스의 상태

프로세스는 상태(State)가 변경되며 수행된다.

프로세스의 상태는 3가지가 있다.

Running
Ready
Blocked

프로세스는 실행하게 되면 CPU의 소유권을 얻기 위해 Ready인 상태로 대기하다 CPU 스케쥴러에 의해 CPU에 소유권을 얻게 되면 Running 상태로 바뀐다.
그러다 I/O나 특정 시스템 콜과 같은 Event를 요청하면 Blocked 상태가 되며 해당 Event가 완료되면 다시 CPU 소유권을 얻기 위해 Ready 상태로 변한다.
혹은 Running 상태에서 Timer Interrupt를 통해 다시 Ready 상태로 변한다.
그렇게 Ready 와 Running을 반복하다 프로세스 동작을 완료하게 된다.

프로세스가 Blocked 상태일 때는 특정 Deivce(H/W) Queue에서 차례를 기다리게 된다.
H/W 뿐만 아니라 S/W 적으로 Blocked Queue가 형성될 수 있다(ex.공유데이터)

이러한 Queue들은 커널이 본인의 Data 영역에 자료구조로 만들어 놓게 된다.

3. Process Control Block(PCB)

PCB란 운영체제가 각 프로세스를 관리하기 위한 프로세스당 유지하는 정보(자료구조)를 뜻한다.
PCB는 크게 4가지의 구성요소를 가진다.

OS가 관리상 사용하는 정보
CPU 수행 관련 하드웨어 값
메모리 관련
파일 관련

CPU는 Queue의 순서대로 실행되는 것 처럼 보이지만 프로세스마다 프로세스의 우선순위가 있어 우선순위가 높은 것부터 실행하게 된다.

4. 문맥 교환(Context Switch)

프로세스가 CPU 권한을 넘겨줄 때 CPU H/W 자체의 PC(Program Counter), 레지스터 상태, 메모리 맵을 커널의 해당 프로세스 PCB안에 저장을 시켜 놓는다.

Context Switch(문맥 교환)은 사용자 프로세스 하나로부터 또 다른 프로세스로 넘어가는 과정이다.
하지만 System Call이나 Interrupt 발생시 반드시 Context Switch가 일어나느 것은 아니다.

예를 들어 프로세스A가 Interrupt나 System Call을 하게 되면 커널에게 CPU 권한이 넘어가게 되고
커널은 ISR이나 System Call 함수를 실행하게 되며 다시 CPU 권한을 프로세스A에게 넘겨주게 된다.
이럴 경우 Context Switch가 발생한 것이 아닌 단순히 Mode가 변환된 것이다.(User Mode -> Kernel Mode -> User Mode)
그렇지만 프로세스A의 코드를 실행하다가 커널의 코드를 실행하기 때문에 아주 약간의 Context는 PCB에 저장하고 있어야 한다.
Context Switch는 위와 같은 경우보다 더 많은 Overhead가 발생하게 된다.

그러나 프로세스A에서 Timer Interrupt나 I/O 요청 Interrupt를 발생하게 되면 커널에게 CPU 권한이 넘어가게 되고 다시 프로세스B에게 권한을 넘겨주게 되면 Context Switch가 발생하게 된 것이다.

5. 프로세스를 스케줄링하기 위한 큐

Ready Queue와 Device Queue는 Job Queue에 포함된다.

Queue에 줄 서있는 것은 프로세스가 아닌 PCB이다.
PCB에는 포인터가 있어 포인터를 활용하여 줄을 서있게 된다.(3. PCB 참고)
Queue는 운영체제가 관리를 하게 된다.

6. 스케줄러

Long-term Scheduler는 어떤 프로세스가 New 상태에 있을 때 해당 프로세스에게 메모리를 주어 Ready로 넘길지 말지를 결정하는 것이다.
Degree of Multiprogramming은 메모리에 올라가 있는 프로세스의 수를 뜻한다.
Degree of Multiprogramming이 너무 많아도, 적어도 컴퓨터 성능은 떨어진다.(효율성이 중요하다.)

보통 시스템에서는 Long-term Scheduler는 거의 없다.
Long-term Scheduler 대신 Medium-Term Scheduler를 사용한다.

Medium-Term Scheduler는 일단 메모리에 프로세스를 전부 올려놓고 너무 많이 올라가 있을 경우 Disk로 쫓아낸다.
Long-term Scheduler는 메모리를 주는 것, Medium-Term Scheduler는 메모리를 뺏는 것이다.

Short-term Scheduler는 다음번에 어떤 프로세스에게 CPU 권한을 줄지 결정하는 것으로 CPU Scheduler로 불리기도 한다.

7. 프로세스의 상태(Porcess State) - Suspended 추가

Suspended는 Medium-Term Scheduler에 의해 메모리르 통째로 빼앗긴 상태이다.(Disk에 Swap out된 상태)
Blocked는 자신의 요청한 일을 하면서 기다리는 상태이다.(Event가 만족되면 다시 Ready상태로 바뀜)

Suspended는 외부에서 정지해놓은 상태이며 외부에서 Resume해주어야 Active한 상태로 넘어갈 수 있다.
Medium-Term Scheduler 뿐만 아니라 외부에 의한 정지로 인해 Suspended가 될 수 있다.

8. 프로세스 상태도 - Suspended 추가

Running(User Mode)는 프로세스가 CPU 권한을 가지고 있으면서 User Mode로 실행중인 상태이다.
Running(Monitor Mode)는 프로세스가 Kernel Mode에서 Running하고 있는 상태이다.
프로세스 상태에 대한 용어(Running, Ready등)는 CPU 입장에서의 용어이다.

Blocked 상태에서 Suspended된 것(Swap out)을 Suspended Blocked라고 하며
Ready 상태에서 Suspenede된 것(Swap out)을 Suspended Ready라고 한다.
Suspended Blocked는 I/O 요청이 완료되거나 Event가 완료되었을 때 inactive한 상태여도 Suspended Ready로 바뀔 수 있다.

3. System Structure & Program Execution 2

eeminsu — Thu, 11 Feb 2021 19:39:48 +0900

KOCW 반효경 교수님 운영체제 강의 정리

이 글은 공부한 것을 복습 및 기록하기 위한 게시물입니다.
잘못된 정보가 기입되어 있을 수 있으니 주의해주시기 바랍니다.
강의 링크 : http://www.kocw.net/home/cview.do?lid=3dd1117c48123b8e

1. 동기식 입출력과 비동기식 입출력

동기식 입출력은 I/O Device까지 가서 어떤 일을 하는 지 보고 결과를 가져와서 다음일을 하는 것이다.
동기식 입출력의 구현방법은 2가지다.

I/O가 끝날 때 까지 CPU 소유권을 가지고 기다리는 것
CPU 소유권을 빼앗기고 I/O가 끝날 때 까지 block 상태로 있는 것

비동기식 입출력은 I/O Device의 일을 기다리지 않고 다음 일을 하는 것이다.

Input은 보통 동기식이며 Output은 비동기식으로 동작한다.

2. DMA Controller

I/O Device로 인해 CPU가 Interrupt에 걸리는 횟수가 너무나도 많아지게 되며 결국 효율적인 동작을 하지 못하게 된다.
이것을 예방하기 위해 DMA Controller가 존재한다.
DMA Controller는 CPU와 동일하게 직접 메모리에 접근할 수 있는 Controller이다.
CPU와 DMA가 동일한 영역의 메모리를 접근할 수 있는 일이 발생할 수 있다.
그래서 Memory Controlle가 접근 순서를 정하여 예방해주는 역할을 한다.

위에서도 언급했다시피 CPU가 직접 I/O Device의 잦은 Interrupt 동작을 수행하는 것은 너무 비효율적이기 때문에
I/O Device가 CPU가 아닌 DMA에게 Interrupt를 요청하고 해당 I/O Device의 Local Buffer작업이 완료되면
DMA가 직접 I/O Device Local Buffer에 내용을 해당 프로그램 메모리 영역에 Copy를 해준 후 CPU에게 작업완료 Interrupt만 요청하게 된다.

위 그림에서 Controller가 DMA이다.
I/O의 작은 일들은 특정 블록만큼 데이터가 쌓이면 CPU에게 Interrupt를 요청한다.
사용자가 키보드 하나 쳤다고 바로 CPU에 Interrupt를 걸면 CPU가 일을 못하게 된다.

Device에서 메모리에 직접 Copy를 하고 그 다음 Interrupt를 한번 걸어서 동작이 완료되는 것을 알린다.

3. 서로 다른 입출력 명령어

I/O를 할 수 있는 방법은 크게 2가지가 있다.

좌측에 있는 방식은 메모리에 접근하는 Instruction과 I/O에 접근하는 Instruction이 따로 있게 된다, 이것이 일반적인 I/O 방식이다.
우측에 있는 방식은 I/O 장치 또한 메모리 주소의 연장 주소로 메모리 Instruction을 통해서만 사용된다.
이것을 Memory Mapped I/O라 한다.

4. 저장장치 계층 구조

위층으로 올라갈수록 속도가 빠르나 단위 공간당 가격이 비싸 용량이 적다.
Secondary(HDD, 테이프)는 비휘발성인 반면 Primary(DRAM, 캐시, 레지스터)는 휘발성이다.

Primary는 CPU에서 직접 접근하는 것이며 Secondary는 CPU가 직접 접근하지 못하는 것이다.
CPU는 Byte단위로 접근이 가능해야 한다.
HDD는 섹터단위의 접근이 필요하여 CPU가 접근하지 못하게 된다.

CPU는 빠르게는 1clock당 instruction을 처리하게 되는데 DRAM은 하나를 처리하는데 많으면 100clock Cycle이 걸리게 되어 매우 오랜 시간이 걸린다.
이러한 속도차이를 완충해주는 것이 바로 캐시 메모리이다.
캐시 메모리는 메인 메모리보다 용량이 작아 당장 필요한 것만 올려 쓰게 된다.
이것을 캐싱이라고 한다.
보통 재사용을 목적으로 사용한다.

5. 프로그램의 실행

어떠한 프로그램을 실행시키게 되면 그 프로그램의 독자적인 Address Space가 형성된다.
Address Space는 Code, Data, Stack으로 구성된다.

Code : 프로그램의 동작 코드
Data : 변수와 같은 프로그램의 자료구조
Stack : 코드의 함수를 호출하거나 리턴할 때 데이터를 쌓거나 꺼내가는 용도

프로그램이 실행될 때 생기는 Address Space를 바로 물리적인 메모리에 올릴 경우 메모리가 낭비가 된다.
실행되는 코드만을 물리적인 메모리에 올리게 된다.
나중에 사용이 되지 않으면 다시 메모리에서 쫓아내어 Disk(Swap Area)에 내려놓게 된다.

File System HDD와 Swap area HDD는 다른 역할을 하게 된다.
File System은 비휘발성이며 Swap area는 휘발성이다.

Address Space의 주소와 물리적 메모리의 주소는 다르게 된다.
이것을 Address translation(주소 변환)이라고 한다.
Address translation은 커널이 하는 것이 아니며 H/W의 도움을 받게 된다.

6. 커널 주소 공간의 내용

커널 또한 일종의 프로그램이다.
그렇기 때문에 커널의 주소공간 또한 Code, Data, Stack으로 구성되어 있다.

코드에는 자원을 관리하는 코드, 시스템 콜, ISR등등의 코드로 구성되어 있다.
Data에는 H/W의 자료구조와 프로그램을 관리하기 위한 자료구조인 PCB등으로 구성되어 있다.
운영체제 또한 함수구조로 코드가 짜여있어 Stack 영역을 사용해야 한다.
여러 사용자 프로그램이 커널의 코드를 쓰기 때문에 커널의 Stack은 사용자 프로그램별로 구성되어 있다.

7. 사용자 프로그램이 사용하는 함수

모든 프로그램은 함수구조로 코드가 짜여져 있다.
사용자 정의 함수와 라이브러리 함수 모두 컴파일 해서 실행파일을 만들면 해당 실행파일 안에 함수가 포함되어 있다.

커널 함수는 사용자 프로그램이 아닌 커널 코드안에 들어 있는 함수이며 사용자 프로그램에서는 호출만 할 수 있다.
커널의 함수는 시스템 콜을 통해서만 사용할 수 있다.

사용자 프로그램의 Address Space와 커널의 Address Space는 영역자체가 다르기 때문에 점프가 불가능 하다.
점프라는 것은 물리적인 메모리가 아닌 프로그램의 논리적인 메모리(가상 메모리)에서 주소를 옮기는 것을 뜻한다.

User Mode : 사용자 프로그램이 CPU를 가지고 있는 것
Kernel Mode : OS(커널)가 CPU를 가지고 있는 것
프로그램은 User Mode와 kernel Mode를 반복하다 종료되는 것이다.

2. System Structure & Program Execution 1

eeminsu — Thu, 11 Feb 2021 19:35:58 +0900

KOCW 반효경 교수님 운영체제 강의 정리

이 글은 공부한 것을 복습 및 기록하기 위한 게시물입니다.
잘못된 정보가 기입되어 있을 수 있으니 주의해주시기 바랍니다.
강의 링크 : http://www.kocw.net/home/cview.do?lid=36f314da6dc42576

1. 컴퓨터 시스템 구조

CPU의 작업공간은 메모리이며 Clock Cycle마다 메모리에서 기계어를 하나씩 읽어서 실행하게 된다.

Device는 Device Controller에 의해 제어된다.
Devcie Controller는 일종의 작은 CPU역할을 하게 되는 것이다.
Device Controller 또한 작업공간이 필요하며 그것을 Local Buffer라 칭한다.

CPU는 메모리에서 instruction(명령어)를 읽어서 실행하게 된다.
CPU안에는 메모리보다 빠르고 정보를 저장할 수 있는 Regiter가 존재한다.

Mode bit는 CPU를 사용하는 것이 운영체제(커널)인지 사용자 프로그램인지 구분할 수 있게 해주는 bit이다.

Interrupt line은 I/O Device에서 요청되는 것을 캐치하는 것이다.
I/O Devcie에서 어떠한 요청이 오게되면 CPU는 Device Controller에게 해당 요청을 처리하게 한다.
Device Controller는 Local buffer에 처리된 결과를 저장해놓는다.
CPU는 처리된 결과 값을 가져와서 다음 동작을 하게 된다.

무한 루프 프로그램이 실행 될때는 CPU가 제대로 된 시분할 동작을 하지 못하게 된다.
이것을 방지하기 위해서 Timer가 존재한다.
Timer는 Interrupt를 통해서 CPU에게 알려주게 된다.
CPU는 1가지의 instruction을 완료하면 Interrupt line을 확인한 후 Interrupt가 없을 시 다음 instruction을 수행한다.

운영체제가 사용자 프로그램의 CPU 소유권을 관리하며 사용자 프로그램은 보안적인 문제 때문에 직접 I/O Device에 접근할 수 없다.
I/O Device에 접근할 수 있는 모든 instruction은 운영체제를 통해서만 접근할 수 있게 된다.

예를 들어 '사용자 프로그램A'에서 I/O Device의 값이 필요하게 되면 해당 Device Controller에게 동작을 요청한다. Device Controller가 동작이 완료된 후 자신의 Local Buffer에 결과 값을 넣게 되면 CPU에게 Interrupt를 걸게 된다. CPU는 interrupt가 오게 되면 진행중이던 다른 '사용자 프로그램B'를 중단하고 운영체제에게 CPU 소유권을 넘기게 된다. 운영체제는 Interrupt 요청을 확인하고 해당 Local buffer 값을 해당 동작을 요청한 '사용자 프로그램A' 메모리에 Copy한다. 이후 interrupt로 인해 중단된 '사용자 프로그램B'에게 timer 시간이 남아있을 때까지 CPU소유권을 넘겨주게 되면서 I/O Device 값이 필요했던 '사용자 프로그램A'에게도 차례가 되면 CPU 소유권을 주게 된다.

2. Mode bit

Mode bit가 0일 때(OS가 CPU를 가지고 있을 때)는 모든 Instruction을 사용할 수 있다.
-> 메모리 영역, I/O Device등등..

Mode bit가 1일 때(사용파 프로그램이 CPU를 가지고 있을 때)는 보안문제 때문에 제한적인 Instruction만 수행하게 되어 있다.

운영체제가 사용자 프로그램에게 CPU 소유권을 넘겨줄 때는 Mode bit를 1로 변경한 후 넘겨주게 되어있다.
Interrupt가 들어오게 되면 CPU 소유권이 운영체제에게 넘어가면서 자동으로 Mode bit가 0으로 변경된다.

3. Timer

TImer는 특정 사용자 프로그램이 CPU를 독점하는 것을 방지하기 위해 존재한다.

4. Device Controller

메모리는 원칙적으로 CPU만 접근할 수 있다.
CPU는 메모리와 Local Buffer에 접근이 가능하다.
Device Controller는 I/O Device의 작업이 끝났을 경우 Interrupt로 CPU에게 그 사실을 알린다.

운영체제 코드 중 각 Device를 접근하기 위한 Device 인터페이스가 존재하게 된다.
Device Driver는 해당 Device 인터페이스에 맞게 접근할 수 있게 해주는 S/W 모듈이다.
그래서 I/O Device(H/W)를 설치하게 되면 해당 Device에 맞는 Device Driver를 설치해야 한다.

예를 들어 메모리의 Instruction 중 I/O Device에 접근을 해야하는 경우가 생긴다면 Device Driver를 통해서 I/O Device의 Device Controller에게 명령을 하게 된다. 예를 들어 Disk에게 명령을 했다고 가정할 때 Device Driver는 Disk에 헤더를 직접 움직이게 하는 코드가 아니라 Disk Controller를 제어하는 코드가 되는 것이다. CPU 또한 직접 일을 하는 것이 아닌 메모리에 있는 instruction을 통해 지시를 받아 일을 하는 것이다. Disk Contorller가 실행하는 Device Driver의 instruction 코드는 Disk가 가지고 있는 F/W를 참고하여 실행하게 된다. Device Driver는 CPU가 실행하는 코드를 담고있다.

5. 입출력(I/O)의 수행 & 시스템 콜 & 인터럽트(Interrupt)

모든 I/O 관련 명령은 운영체제만이 사용할 수 있는 특권명령이다.
사용자 프로그램에서 I/O를 사용할 수 있는 방법은 바로 시스템 콜이다.
시스템 콜은 사용자 프로그램이 OS의 서비스를 받기 위해 커널 함수를 호출하는 것이다.

시스템 콜은 일반 함수호출과 다른다.
사용자 프로그램 안에서의 함수호출은 프로그램안에 메모리 주소를 바꾸면 된다.
시스템 콜은 메모리 주소를 바꾼다고 되는 것이 아닌 복잡한 작업이다.
프로그램이 운영체제에게 어떤 것을 요구하기 위해서 자발적으로 CPU에게 Interrupt를 요청할 수 있다.
운영체제 입장에서는 시스템 콜이 들어왔다고 해서 바로 실행하는 것이 아니라 올바른 명령인지와
요청을 걸어온 사용자 프로그램이 해당 권한이 있는지를 확인한 후 실행하게 된다.

일반적인 Interrupt의 의미는 H/W가 발생시킨 Interrupt이며 S/W가 발생시킨 Interrupt는 Trap이라 한다.
I/O Device를 사용하기 위한 Interrupt는 H/W와 S/W 둘 다 해당하게 된다.
I/O 요청은 S/W, I/O 응답은 H/W

Interrupt 요청이 들어왔을 때 어떤 식으로 대응을 해줄 것인지는 이미 운영체제(커널) 에 함수가 있다.
그것을 Interrupt Service Routine or Interrupt Handler라고 한다.

Interrupt 요청이 들어왔을 때 어떠한 ISR로 가야하는지 표시해주는 것이 Interrupt Vector이다.

운영체제는 CPU를 잡을 이유가 없으며 Interrupt가 발생할 시에만 사용하게 된다.
CPU는 항상 사용자 프로그램에 의해서만 사용되어야 한다.

Deivce Driver 부분이 이해하는데 어려웠다..

1. Introduction to Operating Systems

eeminsu — Sat, 6 Feb 2021 21:12:48 +0900

KOCW 반효경 교수님 운영체제 강의 정리

이 글은 공부한 것을 복습 및 기록하기 위한 게시물입니다.
잘못된 정보가 기입되어 있을 수 있으니 주의해주시기 바랍니다.
강의 링크 : http://www.kocw.net/home/cview.do?lid=af8e05c97c6d60de

1. 운영체제란 무엇인가?

컴퓨터 하드웨어 바로 위에 설치되어 사용자 및 다른 모든 S/W와 H/W를 연결하는 소프트웨어 계층

협의의 운영체제(커널)는 운영체제의 핵심 부분으로 메모리에 상주하는 부분을 얘기한다.
광의의 운영체제는 커널뿐 아니라 각종 주변 시스템 유틸리티를 포함한 개념이다.

2. 운영체제의 목적

운영체제의 목적은 컴퓨터 시스템의 자원을 효율적으로 관리하는데 있다.(자원관리자)
-> 프로세서, 기억장치, I/O등의 효율적 관리

또한 사용자간의 형평성 있는 자원 분배를 해야한다.

운영체제는 H/W 자원(resource)을 효율적으로 관리해주는 것이 가장 중요하다.
또 다른 목적으로는 컴퓨터 시스템을 편리하게 사용할 수 있는 환경을 제공해주는 것이다.

운영체제는 효율성과 형평성을 모두 고려해야 한다.
효율성 - 주어진 자원(resource)으로 최대한의 성능을 내는 것
형평성 - 특정 사용자가 차별받는 상황이 생기지 않는 것

운영체제는 H/W 자원(resource) 뿐만 아니라 S/W 자원(resource)도 관리해야 한다.
사용자는 운영체제 덕분에 H/W 자원(resource)이 어떻게 실행되는지 알 필요가 없다.

CPU는 아주 짧은 시간 간격으로 프로그램을 할당한다.(CPU가 1개일 경우)
워낙 빠르게 진행되어 사용자는 동시에 프로그램이 실행되는 것으로 생각할 수 있다.

메모리 또한 각 프로그램에게 메모리를 할당해주어야 한다.

3. 운영체제의 분류

운영체제는 아래의 3가지 기준으로 분류할 수 있다.

동시 작업 가능 여부
사용자의 수
처리 방식

3-1.동시 작업 가능 여부에 따른 분류

단일 작업(Single Tasking)
한번에 하나의 작업만 처리한다.
다중 작업(Multi Tasking)
동시에 두개 이상의 작업을 처리한다.

현대의 운영체제는 다중작업을 진행해주는 운영체제이다.

3-2. 사용자의 수에 따른 분류

단일 사용자(Single User)
MS-DOS
다중 사용자(Multi User)
UNIX, NT Server

PC 1대를 여러 사용자가 사용할 수 있는지를 기준으로 정의한다.
다중 사용자용일 경우 보안기능이 추가되어야 하며 형평적인 자원관리를 해주어야 한다.

3-3. 처리 방식에 따른 분류

일괄 처리(Batch Processing)
작업 요청의 일정량을 모아서 한꺼번에 처리하는 운영체제이다.
사용자가 작업을 했을 때 바로 반응하지 않는다.
현대 운영체제에서는 보기 어려운 운영체제이다.
ex) 초기 Punch Card 처리 시스템
시분할(Time Sharing)
여러 작업을 수행할 때 컴퓨터 처리 능력을 일정한 시간 단위로 분할하여 사용하는 운영체제이다.
사용자가 입력한 것이 실시간으로 표현되는 느낌을 준다.
시분할은 시간에 제약을 두지 않고 사용자 수에 따라 바뀔 수 가 있다.
사용자가 느끼기에 빠르게 해주면서 주어진 자원(resource)을 최대한 활용하는 것을 목적으로 둔다.
현재 사용하고 있는 운영체제이다.
실시간(Realtime OS)
정해진 시간 안에 어떠한 일이 반드시 종료됨이 보장되어야 하는 실시간 시스템을 위한 운영체제이다.
ex) 미사일 제어, 반도체 장비 등등

시분할과 RTOS 모두 interactive하지만 개념적으로 다르다.
RTOS는 시간에 제약이 있어 반드시 해당 시간에 동작이 되어야 한다.
특수한 목적을 가진 시스템에서 사용된다.

* 실시간 시스템의 개념 확장
Hard realtime system(경성 실시간 시스템) - 시간에 제약이 지켜지지 않을 시 치명적인 결함이 생기는 시스템
Soft realtime systme(연성 실시간 시스템) - 시간에 제약이 지켜지지 않을 시 이를 지키지 않더라도 치명적이 결함이 생기지 않는 시스템

스마트폰 운영체제는 보통 시분할이지만 RTOS가 필요한 부분이 증가되고 있다.
ex) 네비게이션, 블랙박스 등등

3-4. 용어 정리

Multitasking - Task가 여러 개 돌아가고 있지만 CPU에서는 1개의 작업만을 하고있는 것
Multiprogramming - 메모리에 여러 프로그램이 동시에 올가있는 것
Time sharing - Multitasking과 유사하지만 CPU를 좀 더 강조한 의미
Multiprocess - 여러 프로그램이 동시에 진행되는 것
Multiprocessor - 하나의 PC에 CPU가 여러 개 붙어 있는 것을 의미

4. 운영체제의 예

4-1. UNIX

UNIX는 대형컴퓨터를 위해 만들어진 운영체제이다.
Mutitasking을 지원하며 다중 사용자가 이용 가능하다.

초기에는 어셈블리어로 만들어졌다.
대부분에 커널 코드는 C언어로 작성되어 있다.
초창기에 UNIX 코드는 오픈소스여서 누구나 가져다 쓰기 쉽고 교육용, 설계용으로 좋은 표본이 되었다.
대게 개발자가 UNIX 운영체제를 사용하는 것이 수월하였으나 일반 사용자는 사용하기 어려웠다.

UNIX는 C언어를 사용했기 때문에 다른 기계어를 사용하는 PC에도 사용하기 좋아 높은 이식성을 자랑한다.
다만 커널이 커지게 되면 메모리의 대부분을 운영체제가 차지하게 된다.

현재 UNIX는 오픈소스가 많이 사라졌지만 리눅스는 현재까지도 오픈소스이다.
UNIX는 서버용 운영체제이나 리눅스는 서버용 뿐만 아니라 개인용으로도 사용이 가능하다.

안드로이드 커널 또한 리눅스 커널이다.

4-2. DOS(Disk Operating System)

MS사에서 개발한 단일 사용자, 단일 작업 운영체제이다.
주 기억장치가 640KB밖에 되지 않아 메모리 관리 능력의 한계가 있다.
초기에 MS에서는 640KB로도 충분하다고 단언을 하였으나 H/W 발전속도가 빨라 DOS는 망해갔다.

4-3. MS Windows

MS사에서 개발한 다중 작업용 GUI 기반 운영체제로 개인 PC를 위해 만들어진 운영체제이다.
UNIX보다 안정적이지 못하나 요즘 Windows는 불안정성이 많이 해소되었다.

5. 운영체제의 구조

5-1. CPU 스케줄링

어떤 프로그램에 CPU를 할당할 것인지 선정하는 것
일반적으로 CPU 권한을 순서대로 할당하는 것이 합리적이라고 생각하나 컴퓨터에서는 꼭 이러한 방법이 합리적이지만은 않다.

CPU 스케줄링을 순차적으로 처리할 때 한 개의 프로그램이 계속 CPU를 잡고 있을 경우
무슨 행동을 하더라도 작업이 되지 않게 된다.
그래서 시분할을 일반적으로 사용하게 된다.

5-2. 메모리 관리

CPU에서 원활하게 동작하게 할만한 메모리를 할당 받고 있어야 한다.
무조건 메모리를 N분의 1로 나눈다고 해서 원활하게 동작하는 것은 아니다.
메모리 크기는 한정적이여서 메모리가 꽉 찼을 때는 어떠한 프로그램을 Disk로 보낼 것인지를 정해야 한다.
보통 CPU에서 재사용률이 떨어지는 것을 Disk로 보내는 것이 일반적이다.

5-3. 파일 관리

조각조각 나눠 저장하는 것이 좋은지, 일괄적으로 저장하는 것이 좋은지 등을 판단한다.
Disk는 헤드가 움직이면서 파일을 읽기때문에 메모리와는 다르다.
헤드에 가까운 위치에 요청이 있다면 해당 부분에 대해서 먼저 처리를 한다.
엘레베이터 시스템과 유사하다.
동작이 빠른 CPU 스케줄링과 성격이 다르다.

5-4. 입출력 관리(I/O Device)

매우 느리다.
기본적으로 인터럽트에 기반해서 관리가 된다.

5-5. 프로세스 관리

프로세스의 생성과 삭제, 자원 할당 및 반환, 프로세스 간 협력

5-6. 그 외

보호 시스템, 네트워킹, 명령어해석기 등등