[OS] Thread Safe

Intro

🗺 Naver Map sdk를 사용하여 지도화면을 개발하던 중, Multithreading을 만나게 되었다.
예를들어, 지도에서 카페를 클릭하면 지도 위에 카페 마커가 여러개 그려지게 되는데 뭐 100개 안쪽이면 그냥 그려질 수 있겠다.
근데 만약 이 마커가 100개를 넘어서 1000개.. 이렇게 간다면 어떻게 할까?
"카페" 검색만 하고 정말 많은 시간을 로딩을 기다려야 마커가 다 그려질 것 이다.

Naver Map에서 말하는 오버레이 객체는 아무 스레드에서나 접근이 가능하다고 한다.
그러나 오버레이 속성은 스레드 안정성이 보장되지 않기에 여러 스레드에서 동시에 접근해서는 안된다.
✅ 특히, 지도에 추가된 오버레이의 속성은 메인 스레드에서만 접근해야 하며, 그렇지 않으면 CalledFromWrongThreadException을 발생시킨다.

따라서 위에서 말한 것처럼 대량의 오버레이 객체를 다루 경우, 객체 생성+초기옵션 작업은 백그라운드에서 수행하고 지도에 추가하는 작업만 메인 스레드에서 수행해야 효율적이다.

아래는 예제 코드이다.

val executor: Executor = ...
val handler = Handler(Looper.getMainLooper())

executor.execute {
    // 백그라운드 스레드
    val markers = mutableListOf<Marker>()

    repeat(1000) {
        markers += Marker().apply {
            position = ...
            icon = ...
            captionText = ...
        }
    }

    handler.post {
        // 메인 스레드
        markers.forEach { marker ->
            marker.map = naverMap
        }
    }
}

이렇게 Naver Map에서 오버레이 객체 설명을 보다가 thread safe한 개발이 중요하다는 것을 알고 이를 좀 더 정리해보고자 한다.

---

Thread Safe

• Multi-thread Programming에서 일반적으로 어떤 함수나 변수, 혹은 객체가 여러 스레드로부터 동시에 접근이 이루어져도 프로그램의 실행에 문제가 없음을 뜻한다.
• 한 프로그램에서 여러 스레드가 동작해도 문제없이 프로그램이 동작할 수 있는 것.
• 하나의 함수가 한 스레드로부터 호출되서 실행 중일 때, 다른 스레드가 그 함수를 호출하여 동시에 함께 실행되더라도 각 스레드에서의 함수의 수행 결과가 올바로 나오는 것을 의미한다.

Thread가 Safe하지 않다?

스레드가 safe하지 않은 상태라는 것은 무엇이 있을까?
해당 블로그에 좋은 예제가 있어서 가져왔다.

조회수 계산 프로그램

• 100명의 스레드로 각각 100번을 조회할 때

public class CountingTest {
    public static void main(String[] args) {
        Count count = new Count();
        for (int i = 0; i < 100; i++) {
            new Thread(){
                public void run(){
                    for (int j = 0; j < 100; j++) {
                        System.out.println(count.view());
                    }
                }
            }.start();
        }
    }
}
class Count {
    private int count;
    public int view() {return count++;}
    public int getCount() {return count;}
}

위의 코드에서 볼 수 있는 것처럼, 100명의 사람이 각각 100번씩 조회하고 이를 출력하는 시스템이다.
그럼 무조건 10000이 나와야 하는데
참조:https://deveric.tistory.com/104

결과는 그렇지 않다고 한다.

왜?🤔

count를 업데이트 하는 로직은 2가지로 나뉘어진다.
1. 기존의 count를 읽어온다.
2. count에 +1을 해서 다시 저장한다.

1번과 2번 사이에 다른 스레드가 관여하게 되면
나는 22를 가져와서 23을 만들었는데
다른 스레드도 22를 가져와서 23을 만들게 된다.
그럼 일단 위의 한 경우만 생각해도 최종적으로 9999가 나올것이다..
우린 예측할 수 없다. 스레드가 언제 동시에 접근해서 위와 같은 오류가 발생할지 😭

---

동시성을 제어하는 방법

암시적 Lock

가장 간단하면서 쉬운 방법은 Lock을 걸어 버리는 것.
Lock이 적용되면 하나의 스레드가 해당 메서드를 실행 중일 땐 다른 메서드가 해당 메서드를 실행하지 못하고 대기하게 된다.
1번에 하나의 스레드만 접근이 가능하다.
동시성 이슈를 막을 순 있지만 병렬성은 매우 낮아진다.😫

🖐 어떻게 사용할까?
문제가 된 view메서드에 synchronized 키워드를 붙이면 암시적 락이 걸린다.

• lock은 메서드, 변수에 각각 걸 수 있다.
• 메서드에 lock을 걸 경우, 해당 메서드에 진입하는 스레드는 단 하나이다.
• 변수에 lock을 걸 경우, 해당 변수를 단 하나의 스레드만 참조할 수 있다.
• 변수에 lock을 걸기 위해선 반드시 해당 변수는 객체여야 하며 int, long과 같은 기본형 타입에는 lock을 걸 수 없다.

Method Lock

class Count {
    private int count;
    public synchronized int view() {return count++;}
}

변수 Lock

class Count {
    private Integer count = 0;
    public int view() {
        synchronized (this.count) {
            return count++;
        }
    }
}

---

명시적 Lock

synchronized 키워드 없이 명시적으로 ReentrantLock을 사용하는 Lock.

• Lock의 범위를 메서드 내부에서 한정하기 어렵거나, 동시에 여러 lock을 사용하고 싶을 떄 사용한다.
• Lock객체를 생성하여 사용 가능하다.
• lock()메서드를 사용할 경우, 다른 스레드가 해당 lock() 메서드 시작점에 접근하지 못하고 대기한다. unlock()을 실행해야 다른 메서드가 lock을 획득할 수 있다.

public class CountingTest {
    public static void main(String[] args) {
        Count count = new Count();
        for (int i = 0; i < 100; i++) {
            new Thread(){
                public void run(){
                    for (int j = 0; j < 1000; j++) {
                        count.getLock().lock();
                        System.out.println(count.view());
                        count.getLock().unlock();
                    }
                }
            }.start();
        }
    }
}
class Count {
    private int count = 0;
    private Lock lock = new ReentrantLock();
    public int view() {
            return count++;
    }
    public Lock getLock(){
        return lock;
    };
}

---

위와 같이 Thread-Safe를 지키는데는 5가지 원칙이 있다.

1. Re-entrancy

• 어떤 함수가 한 스레드에 의해 호출되어 실행 중일때, 다른 스레드가 그 함수를 호출하더라도 그 결과가 각각에게 올바로 주어져야한다.
• A함수 실행 중, B함수 실행 시키더라도 A,B는 각각 자신의 일을 올바로 수행하는게 당연하다.

2. Thread-local storage

• 공유 자원의 사용을 최대한 줄여 각각의 스레드에서만 접근 가능한 저장소들을 사용함으로써 동시 접근을 막는다.
• 이 방식은 동기화 방법과 연관 있고 또한 공유상태를 피할 수 없을때 사용하는 방법이다.

3. Mutual exclustion

• Thread에 lock이나 semaphore를 걸어서 공유자원에는 하나의 스레드만 접근이 가능하게 된다.

4. Atomic operation

• 데이터 변경 시, atomic하게 데이터에 접근하도록 만든다.

Atomic
: 데이터의 변경이 동시에 일어난 것 처럼 보이게 하는 것.
데이터의 값을 변경하는 것은 시간이 필요하기에 atomic한 데이터의 변경이 이루어지는 시간에는 lock을 건다. 그래서 데이터를 변경하는 시간동안 접근이 이루어지지 않는다.

5. Immutable Object

• 객체 생성 이후에 값을 변경할 수 없도록 만든다.

---

스레드 동기화

A,B가 동시에 실행 될 때, 동시 접근이 안되기에 실행 순서 혹은 메모리 접근에 대해서 동기화를 수행한다. (관점에 따라 2개로 나뉘어진다)

- 실행 순서의 동기화

: 스레드의 실행 순서를 정의하고, 반드시 이 순서를 따르도록 한다.

- 메모리 접근에 대한 동기화

: 데이터 영역과 힙 영역과 같이 한 순간에 하나의 스레드만 접근하도록 하는 것이 메모리 접근에 대한 동기화.
: 만약 2개의 스레드가 동시에 데이터 접근하여 변경한다면 계산 결과가 덮여씌워지는 여러 문제가 발생할 수 있다.

---

동기화를 위한 방법

유저모드 동기화

• User Mode Synchonize
• 동기화가 진행되는 과정에서 커널의 힘을 빌리지 않는(커널 코드 실행X) 동기화 기법
• 따라서 동기화를 위해서 커널 모드로의 전환이 불필요해서 성능상 이점.
• 그만큼 기능 제한도 있다.
  ex) critical section 기반 동기화, inter-lock 함수 기반 동기화

커널모드 동기화

• Kernal Mode Synchronize
• 커널에서 제공하는 동기화 기능을 활용하는 방법
• 동기화 관련된 함수가 호출될 때마다 커널 모드로의 변경이 필요하고, 이는 성능의 저하로 이어진다.
• 하지만 그만큼 유저 모드 동기화에서 제공하지 못하는 기능을 받을 수 있다.
  ex) 뮤텍스 기반 동기화, 세마포어 기반 동기화, 이벤트 기반 동기화

---

volatile

스레드와 동시성을 이야기하다보면 volatile 이야기도 나온다.
위에서 주구장창 이야기 한 것 처럼, 여러 스레드가 공유 자원에 접근을 할 때 이를 무분별하게 접근시키면 오류가 매우 많이 나고 원치 않는 결과를 리턴하게 된다. 그래서 thread-safe하게 프로그래밍을 하는게 중요하다고 했다.

근데 그렇다면 스레드가 접근하는 데이터는 모두 메모리에 존재할까?
정답은 아니다. CPU캐시에 값을 저장하기도 한다.
그래서 해당 데이터가 메모리에 저장된 실제 데이터와 항상 일치할지 보장하지 못한다.
메인 메모리에서 저장된 실제 자원의 값을 볼 수 있는 개념을 자원의 가시성이라고 하는데 이를 충족시키지 못한 경우다.

volatile은 CPU 캐시 사용을 막는다. 키워드로 붙게 되면 해당 변수는 캐시에 저장되지 않는다. 데이터 불일치를 막기 위해 매번 메모리에 저장된다.

그래서 volatile은 자원의 가시성은 확보해주지만 동시성 이슈를 해결하기엔 부족하다. read&write 시점에 동기화를 할 때 해당 연산이 원자성을 이루도록 설정해줘야 비로소 동시성 이슈를 해결할 수 있다.

🖐 volatile은 사용해야 좋을까?

2개의 스레드가 있고 한 스레드는 read만, 한 스레드는 write만 할 경우.
read만 하는 스레드는 cpu캐시에서 값을 확인할텐데 write만 하는 스레드가 넣은 값을 바로 확인하지 못할 수 있다.
이럴 경우, volatile을 붙여 두 스레드가 쓰고 읽는 값의 원자성을 확보할 수 있다. 동시성 이슈 역시 해결 가능하다.

❌ CPU캐시를 비활성화 하고 매번 메인 메모리에 접근하기에 성능 저하가 당연히 발생하기에 유의해서 volatile을 써야한다.

Reference

• Multi Thread환경에서 동시성 제어를 하는 방법
• Thread safe와 동기화 객체