오늘의 배움 #116

2022.01.14 오늘의 배움

오늘 한 일.

• 스노우 코테보기
• 이번 주에 면접본 두 곳 면접 복기
• naljin님 gcd 포스트 쭉 다시 읽어보기 - 항상 느끼지만 글을 진짜로 잘 쓰신다.. 가벼운듯하면서 필요한 내용은 모두 전달하신다. 본받고 싶은 포스팅 실력..

[iOS] 차근차근 시작하는 GCD — 1

• 메인 스레드에서 UI를 모두 처리하는 이유 읽어보기 - 약간 로우레벨 개념이 섞여있어서 쉽지는 않다.

iOS: Why the UI need to be updated on Main Thread

오늘 새로 발견한 것.

• 보라색으로 오류뜨는건 Main Thread Checker가 잡아주는 것이었다.. 백그라운드에서 돌면 안되는 작업을 잡아주는 XCode의 기능이다.
• 보통 같은 큐에서 같은 큐로 sync 를 호출하면 데드락이 일어날 수 있다고 알고있는데, QoS를 다르게 주면 QoS마다 사용하는 스레드가 분리되어 있어서 데드락이 안난다고 한다.
• 클로저에서 클로저 외부의 정보(self 포함)을 사용하면 강한 참조로 캡쳐된다. weak self 쓰는게 이걸 약한 참조로 바꿔주는 것이다.
• DispatchGroup을 쓸 때, notify를 호출하는 방법 말고도, 그룹에 wait을 걸어서 그룹을 만든 현재 스레드를 블록시킬 수 있다. 그리고 여기에 타임아웃을 파라미터로 주는 것도 가능하다. 타임아웃이 인자로 들어가면 wait의 반환 타입은 DispatchTimeoutResult 가 된다. Result 객체처럼 success, failure로 접근하고 지정했던 시간안에 작업들이 모두 끝나면 success, 끝나지 않은 작업이 있으면 failure가 반환된다. 
• 이때 wait을 호출한 스레드가 블록되기 때문에 당연히 메인 스레드에서는 호출하면 안된다.
• 그룹 안에 비동기 작업이 없으면 그냥 async에 파라미터로 group을 주면 되지만, 비동기 작업이 있으면 비동기 작업을 시작하기 전에 enter, 끝나면 completion에서 leave를 호출해서 명시적으로 group에 작업이 끝났음을 알려야한다. 
• DispatchWorkItem으로 캡슐화한 작업은 async(execute: )으로 실행하거나, .perform으로 현재 스레드에서 sync하게 실행할 수 있다.
• DispatchWorkItem의 cancel을 호출하면 작업이 아직 큐에서 대기중일 때는 작업이 취소되지만, 이미 시작한 작업은 플래그만 바꾸고 작업이 중단되지는 않는다.
• 작업간의 의존성을 만들려면 OperationQueue가 제일 깔끔하긴 하지만, DispatchSemaphore로 순서를 맞추는 것도 가능하다. 대신 이러면 사실상 시리얼 큐에 sync로 작업을 보내는거랑 별로 다를게 없을 것 같다.
• 경쟁상태를 막기 위해 barrier 를 사용할 수 있는데, 쓰기작업은 barrier로 시작해서 쓰기가 일어나는 동안에는 다른 스레드에서 쓰기작업이 일어나지 않도록 하고, 읽기 작업은 자유롭게 공유자원에 접근하게 할 수 있다.
• barrier 블럭이 시작되면 다른 애들이 작업을 멈추는게 아니라, 기존에 작업중이던 애들이 종료되면 그때서야 barrier를 준 블럭을 실행한다.
• barrier를 쓰려면 async(flags: .barrier, execute: {Task}) 로 주면된다.

• var name: String {
    get {
      self._name
    }
    set {
      concurrentQueue.async(flags: .barrier, execute: {
        self._name = newValue
        print(self._name)
      })
    }
  }

• 데드락을 막으려면 그냥 시리얼 큐를 쓰면 된다. 그럼 무조건 한번에 한 스레드만 실행되니까. 근데 그렇다고 무조건 시리얼 큐만 쓰면 성능에 손해를 보니까 설계가 잘 되어있는지 보면서 적절하게 대응해야한다.
• Priority Inversion은 우선순위가 낮은 태스크가 우선순위가 높은 태스크가 필요한 자원을 점유하게 되면서 우선순위가 뒤집혀버리는 상황을 말한다.
• 실제로는 시리얼 큐에서 qos가 낮은 태스크가 먼저들어온 뒤에 qos가 높은 태스크가 들어와서 우선순위가 의미없어지는 상황이나,  Operation queue에서 qos가 높은 태스크가 qos가 낮은 태스크의 의존성을 가지게 될 경우에 발생할 수 있다.
• low, mid, high 순으로 작업이 도착하고, low가 high에서 필요한 자원을 점유하고 있다면, high가 시작되어서 CPU를 선점하면 low가 끝나길 기다리면서 대기하게 되고, 다음 우선순위인 mid가 먼저 실행되고 종료된다. high는 low보다 무조건 늦게 끝나야하기 때문에 mid->low->high 순으로 작업이 처리된다. 
• GCD에서는 이걸 막으려고 그냥 자원을 점유하는 스레드의 qos를 임시적으로 높여버린다. 이렇게 하면 위에랑 똑같은 환경에서도 high가 들어와서 low의 자원을 위해 대기할 때, GCD가 low의 우선순위를 high로 올려버려서 남은 작업을 다 처리하고, low가 끝나면 high가 실행되므로 low->high->mid 순으로 실행되어서 서로 의존관계가 없는 high와 mid의 우선순위가 역전되지 않는다.

오늘 느낀 것.

• 가장 가고싶던 기업의 최종면접을 보게 되었다. 최종을 본다는 것도 얼떨떨한데 다시 또 CS랑 플젝이랑 Rx랑 준비하고 면접가서 영혼탈곡 당할 걸 생각하니 너무너무 무섭지만 그래도 최선을 다해봐야겠다.
• 스노우 코테는 앞 두 문제가 생각한대로 너무 잘 풀려서 기분 좋았는데, 마지막 문제에서 시간을 너무 많이 잡아먹어서 해결을 못했다ㅠ 이것도 결과를 기다려보자!
• 면접을 복기하면서 가장 많이 든 생각은 "아 더 나은 대답이 있었는데 왜 그렇게 말했지?"였다.. 하다보면 점점 나아지겠지?
• 전형의 결과들이 조금씩 나오면서 긴장이 풀렸는지 어제 오늘은 계속 잠을 많이 잤다.. 내일부터는 다시 집중을 해보자!

내일의 계획.

• 면접준비. 이제 알고리즘 보는 전형은 다 끝나서 알고리즘은 멈추고 다시 CS, iOS, Rx, 플젝 정리를 해야할 것 같다.

오늘의 감사.

• 진짜로 다 감사합니다! 마지막까지 어떻게 되든 지금까지의 노력을 이렇게라도 인정받게 해주셔서 감사해요!