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

안녕하세요 록원 님.

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

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

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

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

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

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

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


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

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

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

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


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


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

고맙습니다.