무언가를 잘하고 전문가가 된다는 것은 참 어려운 일인 것 같습니다. 비록 6개월 전까지만 하더라도 참 저는 빠르게 성장하고 있다고 생각했는데 아니란 것을 알게 되고 나서는 며칠간 힘들었던 것 같습니다.

더닝 크루거 현상은 항상 저같은 아마추어들에게 가르침을 주는 것 같습니다. 자신감도 많이 떨어졌는데 더 떨어질 게 한참 남아있는 것 같아 조금은 무섭지만 그래프에서 알 수 있는 건 어찌됐는 제가 모르는 것이 무엇인지를 알기 시작하는 지점에 도달한 거 같아 긍정적으로 생각됩니다.

Race condition

동기화 문제는 운영체제에서 중요한 이슈입니다. 만약 공유되는 데이터를 두개의 프로세스에서 동시에 접근한다면 어떻게 될까요? 두 프로세스 모두 같은 변수를 가지고 하나씩 더해 2가 더한 값을 기대했지만 결과적으로 1만 더해질 수 있다는 의미입니다. 이처럼 많은 작업이 꼬여서 엉망이 될 것입니다. 이런 문제를 Race condition 경쟁상태라고 합니다. 기본적으로 모든 프로세스는 cpu를 얻기위해 경쟁하는 상태이기 때문에 발생합니다.

그리고 공유되어져 충돌의 위험이 있는 데이터 부분을 우리는 critical section이라고 합니다.

기본적으로 충돌을 방지하기 위해서는 조건이 필요합니다.

1. 상호배제(mutaul exclusion) - 한 프로세스가 수행중이라면 다른 모든 프로세스는 critical section에 들어가지 않으면 됩니다.

2. 진행(progress) - 아무도 critical section에 없다면 들어 갈 수 있어야 합니다.

3. 대기 제한(bounded waiting) - critical section에 들어가려고 요청한 그 후부터 그 요청이 허용될때까지 다른 프로세스들이 critical section에 들어가는 횟수에 한계를 두어야 합니다. 즉 critical section에 들어가려고 기다리고 있던 프로세스는 언젠간 꼭 한번 들어가게 해줘야 한다는 의미와 같습니다. - starvation 방지

전통적인 동기화 문제 3가지입니다.

1. 생산자 - 소비자 문제
   생산자-소비자 문제는 생산자가 데이터를 생상하면 소비자는 그것을 소비하는 형태에서 발생하는 문제를 말합니다. 컴퓨터 세계에서 예를 들면 웹 서버와 웹 클라이언트로 들 수 있습니다. 웹 서버가 데이터를 생산하여 웹에 관련되어 보여주는 작업들을 수행하고 웹 클라이언트는 웹 주소로 접속해 화면을 통해 보게 되는 형태의 소비 작용을 합니다.
   일반적으로 생산하는 속도와 소비하는 속도에 차이가 존재하는데 실제로 생산되는 속도가 소비하는 속도보다 빠른 경우가 많아서 생산된 데이터는 바로 소비되지 못합니다. 이를 보안하기 위해 생산된 데이터를 보관하는 버퍼라는 공간이 존재합니다. 생산자가 데이터를 생산하면 버퍼에 보관을 하게 되고 소비자는 버퍼에서 데이터를 빼내어 사용합니다. 하지만 현실 시스템에는 버퍼의 크기가 유한하고 크기가 정해져 있는 버퍼이기 때문에 Bounded Buffer라고 불립니다. 생산자는 버퍼가 가득 차면 더 이상 넣을 수가 없게되고 반대로 소비자는 버퍼가 비면 뺄 수가 없게됩니다.
   이것 뿐만 아니라 동시에 생산과 소비가 같은 버퍼에서 일어난다면 데이터 유실이 발생할 수 도 있습니다.

2. 읽기 쓰기 문제
   공유되는 데이터를 읽는 것은 동시에 접근이 가능해야 하고, 쓰는 것은 하나의 프로세스만 가능하게 해야하는 문제입니다. 만약 읽기 쓰기 작업 모두 다 상호배제를 걸어 둔다면 우리는 너무 비효율적으로 작업할 것입니다. 반대로 두 작업 모두 상호배제 없이 둔다면 읽는 것은 문제가 안되겠지만 쓰는 것은 데이터 유실이나 중복된 데이터가 무더기로 발견될 것입니다.

3. 밥먹는 철학자 문제
   
   5명의 철학자는 밥을 먹으며 생각을 하고 있습니다. 밥을 먹고, 생각을 반복합니다. 각각 철학자들은 젓가락 한 개만 가지고 있습니다. 생각을 할 때에는 젓가락을 내려놓습니다. 밥을 먹기위해서는 두 개의 젓가락을 써야합니다. 젓가락은 공유자원입니다.
   만약 이런 상황에서 동시에 젓가락을 한 개씩 동시에 들게되면 어떻게 될까요? 바로 데드락이 걸려버리고 맙니다. 아무도 밥을 먹지 못하고 생각도 하지 못하는 상황에 빠지게 됩니다.

우리는 대표적인 문제 3개를 보았고 이것들은 대부분 상호배제, 진행, 대기제한 때문에 문제가 생긴다는 것을 보았습니다.
우리는 이를 어떤 식으로 해결할 수 있을까요? 가장 대표적인 해결방법으로는 뮤텍스와 세마포어가 있습니다.

뮤텍스는 사실 세마포어 종류중 하나입니다. 즉 세마포어에 뮤텍스가 포함되어 있는 관계입니다. 세마포어와 뮤텍스의 가장 큰 차이점은 1개 이상의 프로세스가 접근 할 수 있냐 없냐에 따라 있습니다.

만약 세마포어가 bin값으로 2가지 밖에 없다면 뮤텍스라고 할 수 있습니다. 하지만 가끔 공유데이터에 2개 이상의 프로세스가 접근 할 수 있게 해야합니다. 우리는 이때 세마포어를 사용하면 됩니다. 추가적인 차이점으로는 뮤텍스는 주로 쓰레드의 경쟁 상태를 막는 것에 많이 쓰이고 세마포어는 프로세스간 공유된 자원 문제를 해결하기위해 사용합니다.

세마포어는 리소스의 상태를 나타내는 간단한 카운터로 생각할 수 있습니다. 일반적으로 비교적 긴 시간을 확보하는 리소스에 대해 이용하게 되며, 유닉스 시스템의 프로그래밍에서 세마포어는 운영체제의 리소스를 경쟁적으로 사용하는 다중 프로세스에서 행동을 조정하거나 또는 동기화 시키는 기술입니다.

그렇기 때문에 뮤텍스는 두 개의 쓰레드가 공유할 수 없지만, 세마포어는 반면 여러 프로세스가 소유할 수 있습니다.