[Swift🦩] #26 메모리 안전성

• Swift 는 기본적으로 코드에서 발생하는 불안전한 동작들을 자동으로 방지해준다.
• 변수가 사용 전에 초기화 되어 있는지, 할당 해제 후에는 접근하지 않음.
• 배열 인덱스 범위를 벗어나는지 ...

• 메모리 위치를 수정하는 코드가 해당 메모리에 대한 독점 권한을 가지도록 요구해서
• 동일한 메모리 영역에 다중 접근이 일어나지 않도록 한다.
• 하지만, 잠재적으로 충돌이 발생할 수 있다.
  • 컴파일 / 런타임 에러 발생.

1. 메모리에 충돌하는 접근 이해

• 변수의 값을 설정하거나
• 함수에 인자를 전달하는
• 동작을 할 때 메모리에 접근하게 된다.

var one = 1 // 쓰기 접근.

print("We're number \(one)!") // 읽기 접근.

• 코드의 다른 부분이 같은 시간에 메모리의 같은 위치에 접근할 때 충돌이 발생할 수 있다.
• Swift 에서는 자체 수정 중에 값에 접근할 수 있다.

예시) 아래에서 중간 상태는, 새로 반영된 물품의 가격이 total 에 적용되지 않은 상태이다. 여기서 total 에 접근하게 되면 잘못된 값이 나온다.

NOTE : 동시 / 다중 쓰레드 코드를 작성한 경우 메모리 충돌이 빈번하게 발생한다. 하지만 예시는 단일 쓰레드에서 충돌이 발생하는 경우이다.

단일 쓰레드 내 충돌은 컴파일 / 런타임 에러를 일으키게 되고,
다중 쓰레드 코드는 Thread Sanitizer 를 사용해서 쓰레드 간 충돌을 일으키는 접근을 감지할 수 있다.

메모리 접근의 특징

아래 3가지 조건을 모두 만족하는 2개의 접근이 있다면 충돌이 발생한다.

• 적어도 하나는 쓰기 접근 (메모리 위치를 변경) 이거나 non-atomic (C atomic 연산이 아닌 것) 접근이다.
• 메모리의 같은 위치에 접근한다.
• 접근 시간이 겹친다. (순간적 / 장기적)
  • 접근이 시작되고, 종료되기 전에 다른 코드를 실행할 수 없는 경우에는 접근은 동시에 이루어진다.
  • 메모리에 2개의 즉시 접근은 일어날 수가 없다.
  • 메모리에는 즉각적인 접근이 일어남.

그런데... 다른 코드의 실행에 걸친 경우, 메모리에 장기 접근을 하게 된다면...

• 장기 접근이 시작되고 종료되기 전에 다른 코드가 실행될 수 있다. -> 오버랩
• 장기 접근은 장기 / 즉각 접근과 오버랩 될 수 있다.
  • inout 파라미터를 사용하거나
  • 구조체를 변경하는 mutating 메서드를 사용하는 코드에서 나타날 수 있다.

2. In-Out 파라미터에 충돌 접근

• 함수는 모든 in-out 파라미터에 대해 장기 쓰기 접근 을 하게 된다.
• non-in-out 파라미터가 평가된 후에 in-out 파라미터에 쓰기 접근을 시작하고, 함수가 호출되는 동안 쓰기 접근이 지속된다.
• inout 파라미터가 여러개면 inout 파라미터가 나타나는 순서대로 메모리 쓰기 접근을 시행한다.

문제1 : 전달된 원래 변수에 접근할 수 없다.

var stepSize = 1

func increment(_ number: inout Int) {
    number += stepSize // stepSize 를 전달했는데 안에서 stepSize 에 접근 -> 오버랩 충돌.
}

increment(&stepSize)
// Error: conflicting accesses to stepSize

해결1 : setpSize 의 복사본을 지정해서 inout 파라미터로 보낸다.

// Make an explicit copy.
var copyOfStepSize = stepSize
increment(&copyOfStepSize) // 복사본을 함수의 인자로 보냄.

// Update the original.
stepSize = copyOfStepSize
// stepSize is now 2
// 읽기 접근이 쓰기 접근이 시작되기 전에 끝남

문제2 : inout 파라미터에 단일 변수를 넘기면 충돌이 발생한다.

• 연산자 역시 함수이므로, inout 파라미터를 넘기는 연산자라면 메모리 접근 충돌이 발생할 수 있다.

func balance(_ x: inout Int, _ y: inout Int) {
    let sum = x + y
    x = sum / 2
    y = sum - x
}
var playerOneScore = 42
var playerTwoScore = 30
balance(&playerOneScore, &playerTwoScore)  // OK : 두 쓰기 접근이 오버랩 되지만 다른 주소에 접근하는 것이므로 상관 없음.
balance(&playerOneScore, &playerOneScore) // Error: 오버랩 되며 같은 주소에 접근함 -> conflict

3. 메서드에서 self 에 충돌 접근

• 구조체의 mutating method 는 메서드가 호출되고 반환될때 까지 self 에 대한 쓰기 접근을 가진다.

struct Player {
    var name: String
    var health: Int
    var energy: Int

    static let maxHealth = 10
    mutating func restoreHealth() {
        health = Player.maxHealth
    }
}

// sharedHealth 라는 함수를 만들면, self (Player) 에 대한 중복 접근 가능성이 생긴다.
extension Player {
    mutating func shareHealth(with teammate: inout Player) {
        balance(&teammate.health, &health)
    }
}

var oscar = Player(name: "Oscar", health: 10, energy: 10)
var maria = Player(name: "Maria", health: 5, energy: 10)
oscar.shareHealth(with: &maria)  // OK : 오버랩은 되나 다른 주소에 접근하고 있음.

하지만 본인과 체력을 공유한다면..? 충돌.

oscar.shareHealth(with: &oscar)
// Error: conflicting accesses to oscar

4. 프로퍼티에서 충돌 접근

• 값 타입의 경우 개별 구성값으로 구성되고,
• 일부분을 변경하면 새로운 주소에 변경된 구조체를 할당하고 거기를 참조해서 전체 값이 변경된다.
• 프로퍼티 중 하나에 읽기 / 쓰기 접근을 요구하거나, 전체 값에 읽기 / 쓰기 접근을 요구하게 된다.
• 튜플의 요소에 쓰기 접근이 겹치면 충돌이 일어나게 된다.

var playerInformation = (health: 10, energy: 20)
balance(&playerInformation.health, &playerInformation.energy)
// Error: conflicting access to properties of playerInformation 같은 튜플 인스턴스에 대한 쓰기 접근을 요구하면서 오버랩 되어 충돌

var holly = Player(name: "Holly", health: 10, energy: 10)
balance(&holly.health, &holly.energy)  // Error : 같은 구조체 인스턴스에 대한 쓰기 접근 오버랩 -> 충돌 
// 다른 변수가 holly 에 접근해서 뭔가를 바꾸는 도중에 balance 가 실행될 수 있기 때문에 충돌.

해결 : holly 가 전역 변수가 아니라 지역변수라면 중복 접근이 안전할 수 있음. 2개의 저장된 프로퍼티가 어떤식으로도 상호작용하지 않기 때문이다. 근데... 왜?

func someFunction() {
    var oscar = Player(name: "Oscar", health: 10, energy: 10)
    balance(&oscar.health, &oscar.energy)  // OK : health 와 energy 가 상호작용하지 않을 거라고 보장이 됨 by 컴파일러 - 
    // balance 가 한번만 실행되고 있고, 지역 변수라서 함수 내부에서만 쓰이고 없어지기 때문. 
    // 다른 것이 oscar 변수에 접근할 우려가 없다.
}

• 구조체의 프로퍼티에 중복 접근에 대한 제한은 메모리 안정성을 위해서 항상 필요한 영역은 아니다.
• 메모리에 대한 배타적 접근 이 메모리 안정성보다 중요하다.
• Swift 컴파일러는 배타적이지 않은 접근이 안전하다고 증명되면 메모리 안전 코드를 허용하게 된다.
  • 계산된 프로퍼티, 클래스 프로퍼티가 아닌 인스턴스의 저장된 프로퍼티만 접근
  • 구조체는 전역 변수가 아닌 지역 변수의 값임
  • 구조체는 클로저에 의해 캡쳐되지 않거나 non-escaping 클로저에 의해서만 캡처된다.

참고

https://bbiguduk.gitbook.io/swift/language-guide-1/memory-safety#in-out-conflicting-access-to-in-out-parameters