인프런 커뮤니티 질문&답변

rokwon님의 프로필 이미지
rokwon

작성한 질문수

앨런 iOS Concurrency(동시성) - 디스패치큐와 오퍼레이션큐의 이해

큐로 sync하게 호출하는 이유가 궁금합니다

작성

·

185

2

안녕하세요! 좋은 강의 정말 잘 듣고 있습니다ㅎㅎ
 
다름이 아니라 Dispatch Barrier강의를 듣던 중 궁금한 점이 생겼습니다.
get, set 각각 다른큐로 sync, async하게 넘기는 예시를 보았습니다.
여기서 궁금한 점이 생겼는데 get을 하는데 굳이 큐로 sync하게 넘기는 이유가 있을까요? 현재 쓰레드에서 그대로 get을 하면 다른 쓰레드로 넘어가는 낭비를 하지않고 그대로 받아 올 수 있지 않나요?
여기서 조금 더 나아가서 현 쓰레드에서 큐(다른 쓰레드)로 굳이 sync하게 넘어가야할 이유를 모르겠습니다. 어차피 현 쓰레드가 동작하지 못하고 기다릴 바에야 현 쓰레드에서 모든 걸 처리하면 되지 않나요?

답변 1

1

앨런(Allen)님의 프로필 이미지
앨런(Allen)
지식공유자

안녕하세요 록원 님.

이해하실 것 같아 조금 간단하게 말씀드리자면..
단순하게 읽어오는 작업이라면,
굳이 다른 쓰레드로 보내지 않고 그대로 읽어오는 작업을 해도 괜찮습니다.
(읽기 작업의 경우 굳이 Thread-safe하지 않아도 괜찮으니까요.)

그런데, Barrier프로젝트에서는 하고자하는작업의 특성때문에
(1) 배리어를 사용하는 큐로 (2) sync하게 넘겼다고 말씀드릴 수 있을 것 같아요.

일단은 어떤 특성때문인지 말씀드리면..
읽기(read) 작업 전후로 쓰기(write) 작업이 있기 때문에..

아래와 같은 그림의 예시처럼 처럼..


 

제가 예시로 사용하고 있는 프로젝트의 경우..
이름을 쓰고(write) 있는 동안에, 읽기(read) 작업이 일어날 수 있기 때문에(배리어 적용 전)
즉, 원하는 이름을 얻지 못하는 상황이 발생할 수 있기 때문에

이것을 쓰레드 세이프하게 처리하기 위해서,
배리어(Barrier)라는 것을 사용한 것이고요 !

(1) 
배리어를 효과를 사용하려면,
다른 작업들도 배리어 작업과 동일한 큐로 보내줘야 합니다.
그래서 배리어 작업과 동일한 큐로 보내준 것이지요.


(2) 
그러면 왜 sync로 보내주었을까?
라고 생각해보면..

읽기 작업의 경우, 현재의 쓰레드에서 원래의 작업이 일어나고 있고,
다른 쓰레드에 다시 읽기 작업을 시킬 경우
async를 사용할 수가 없습니다. 

이유는 간단한데요, sync라는 것은 기다린다는 의미이고..
(다른 쓰레드로 보내) 실제 값을 얻어올때까지 기다려야 한다는 것을 의미하죠.

즉, 이해하기 쉽게 조금 설명드리면.. async로 읽기 작업을 보내버리면..
값을 얻어오지 못하는 (쉽게 말씀드리면 값을 얻기 전에 쓰레드로 복귀하기 때문에.. 실제 값을 얻지 못해 nil과 같은 상황이 발생 가능) 일이 발생합니다.


그래서.. 결론적으로 정리해서 말씀드리면
(여기서는 Thread-safe한 처리를 하는 것이 목적이니)
배리어 적용을 위해서, 읽기 작업 또한 배리어(장벽)이 적용되도록 하기 위해서
쓰기 작업과 동일한 (1) 다른 큐로 보냈고, (2) 읽기 작업은 다른 쓰레드로 보낼때 sync만 가능하기 때문에
그런 것이죠.


혹시나 이해가 안되시면 다시 질문 남겨주세요. :)

고맙습니다.

rokwon님의 프로필 이미지
rokwon
질문자

넵 앨런님 정말 친절하고 자세한 설명 감사드립니다!!!

배리어 효과를 보기 위해서는 동일한 큐를 사용해야한다. 이 부분이 제가 놓친 부분이었네요. 꽁꽁 싸매고 바보같은 고민만 했는데 친절하게 답변해주셔셔 바로 이해가 갔습니다! 다시 한 번 감사드립니다ㅎㅎ

rokwon님의 프로필 이미지
rokwon

작성한 질문수

질문하기