Home [멀티쓰레드] Lock 구현 이론
Post
Cancel

[멀티쓰레드] Lock 구현 이론

Lock 구현 이론

Lock을 직접 구현해본다고 생각하고 Lock이 어떤 철학으로 어떤식으로 구현될 수 있을지 생각해보자.

일단 기본적으로 당연히 Lock의 역할을 하기 위해서는 Critical Section(임계 구역)에 두 프로세스가 동시에 진입하지 못하도록 해야할 것이다.
그 다음으로는 이미 다른 프로세스가 들어와 사용하고 있을 때 어떻게 처리할지를 생각해봐야 할 것이다.

일상생활에 비유해보자면 공용 화장실에 이미 누가 들어가 문을 잠군 상태이고 난 문앞에서 기다리고 있는 상황이다.

이때 내가 할 수 있는 행동으로는 아래와 같을 것이다.

  1. 그냥 무작정 기다린다.
  2. 일단 돌아가 있다가 나중에 다시 와본다.
  3. 주변에 직원분이 있다면 부탁드리고 돌아와 있다가 직원분이 화장실이 비었다고 전달해주면 그때 다시 가본다.
  4. 기타…

Lock을 구현할 때도 위와 동일하다. 이미 누가 점유해 사용하고 있을 때 아래와 같이 대처할 수 있을 것이다.

  1. 그냥 무작정 기다린다.
  2. 일단 다른 작업으로 돌아가 있다가 나중에 다시 와본다.
  3. Event call back 방식으로 누군가에게 다시 사용할 수 있는 상태가 되면 호출해 달라한다.

1번 방법은 실제로 있는 개념으로 Spin Lock이라고 한다. 그냥 무작정 기다리는 형태이기 때문에 구현은 단순하겠지만, 기다린다는 것이 실제로 가만히 있는 것이아니라 while문 형식으로 무작정 시도하는 형태이기 때문에 작업이 결코 가볍진 않다.

2번 방법의 경우 무작정 체크를 하는 것이 아닌 일단 다른 작업으로 돌아가 있다가 랜덤한 시간 이후에 다시 돌아와 체크하는 방식이다. 1번과 다르게 기다리는 동안 다른 작업을 할 수 있다는 장점이 있지만, 작업을 계속 왔다 갔다하는 것이 결코 가볍지 않고 잠깐 다른 작업을 하고 오는 사이에 또다른 쓰레드가 점유해 있을 수도 있다.

3번 방법은 2번과 비슷하지만 랜덤한 시간 이후에 다시 돌아오는 것이 아니라 커널(운영체제)한테 Event call back 방식으로 나중에 다시 사용가능해지면 호출해달라고 부탁해놓고 나오는 방식이다. 이렇게 할 경우 매번 돌아와 체크할 필요가 없어진다는 장점이 있지만, 이렇게 부탁하는 쓰레드가 많아질 수록 커널(운영체제) 입장에서는 부담이 커질 수 있다.

This post is licensed under CC BY 4.0 by the author.