병렬처리를 사용하는 프로그램을 개발하다가 CompletableFuture의 블로킹 논블로킹 메서드들을 알아보다가 내가 블로킹(Blocking)에 대한 정의를 명확하게 알지 못한다는걸 알게됐다.

Blocking의 뜻

Blocking은 일반적으로 둘중 하나의 의미로 쓰인다.
1. 제어권의 상실
2. 다른 스레드의 작업이 끝날 때 까지 스레드의 대기 상태 진입

제어권이 있는지의 여부는 어떤 작업 진행 도중 다른 작업이 진행되는 동안 작업을 계속 할 수 있는지의 여부로 볼 수 있다.

일단 '2. 스레드의 대기 상태 진입'은 '1. 제어권의 상실'의 부분집합으로 볼 수 있겠다.

AtomicInteger#incrementAndGet 은 Non-Blocking?

제어권

이 메서드는 Blocking 메서드일까?
위에서 언급한 Blocking의 의미 중 첫번째인 제어권의 상실 여부로 판단하자면 당연히 Blocking 메서드다. 작업이 끝나야 리턴을 하기 때문이다. 이 정의에 따르면 Math.pow, String.split 등의 비동기 작업과 무관한 대부분의 메서드가 Blocking 메서드다.
이러한 점을 고려했을 때 AtomicInteger#incrementAndGet 메서드의 Blocking 여부를 따진다면 맥락상 두번째 의미의 Blocking 여부를 따지는 것으로 볼 수 있다.

스레드

당연히도 CAS 연산을 수행한다고 Thread의 상태가 변화하지는 않는다. 따라서 두 번째 정의에 따르면 Non-Blocking이다. busywaiting과 유사한 점이 있는 것 같다.

두개의 스레드 A, B가 각각 다른 코어에서 실행되고 있다고 해보자. 둘다 f라는 volatile 필드에 대해 CAS 반복문을 돌리고 있다.
CAS 연산이 프로세서에 의존적이다. 프로세서는 CAS 명령을 구현하기 위해 내부적으로 하드웨어적인 lock을 건다고 가정 해보자. A 스레드에서 CAS 연산을 하는 도중 B 스레드가 CAS 연산을 지시한 상황을 생각해 봤을 때 B스레드를 실행중인 코어에서 CAS 연산을 지시했을 때의 인위적인 지연은 있을 것이다. 하지만 그렇다고 스레드 자체의 상태의 변경이나 문맥교환이 발생하는 건 아니다. 따라서 Non-Blocking이다.

당연한 사실이지만 하드웨어 수준에서의 지연은 발생한것을 고려해 봤을 때 컴퓨터에서 완전한 병렬성과 원자성의 양립은 불가능하다고 생각해볼 수 있다. 정의에서 부터 충돌하는 개념들이다.