엑스코드 14.1
iPhone 14 pro(iOS 16.1) – 시뮬레이터
이번 포스팅에서는 동시성(concurrency)에 대해 계속 알아보도록 하겠습니다.
1. 구조화되지 않은 동시성(구조화되지 않은 동시성)
지난 포스팅에서 명시적 부모-자식 관계의 구조화된 동시성나는 그것에 대해 알게 되었다
이번에는 위의 관계와 같은 구조화되지 않은 동시성을 살펴보겠습니다.
프로그램에 작업을 추가할 때 항상 계층 구조에 추가할 필요는 없습니다.
구조화되지 않은 동시성은 수동 관리가 필요하지만 상대적으로 더 유연한 작업 처리를 제공합니다.
일
WWDC 세션의 예를 사용하여 구조화되지 않은 동시성 작업을 만드는 방법을 살펴보겠습니다.
아래 예제의 collection view 방식은 @주연 주석에 따라 메인 캐스트에서 작동한다고 가정합니다. 간단히 메인 스레드에서 기능가다 당신이 이해한다면 마치
배우들에 대해서는 다음 포스팅에서 다루도록 하겠습니다!
CollectionView 델리게이트의 willDisplay 메소드에 표시할 셀의 썸네일을 검색해야 한다고 가정합니다.
여기 미리보기 이미지를 로드하는 방법은 비동기식입니다.로 구현한다고 가정하면 코드는 다음과 같이 구성할 수 있습니다.
단, 위의 코드에서는 위임 방식이 구현되어 있습니다. 이것은 비동기 메서드가 아니므로 내부적으로 await를 사용하면 오류가 발생합니다.하다.
그렇다면 이 경우 어떻게 비동기 함수를 호출할 수 있을까요?
이 문제는 작업 트리에서 직접 작업을 생성하여 해결할 수 있습니다.
|
내부에(우선 사항: 작업 우선순위?, 작업: () 비동기 –> 성공) // 성공은 전송 가능, 실패는 절대 전송되지 않음
내부에(우선 사항: 작업 우선순위?, 작업: () 비동기 던진다 –> 성공) // 성공은 전송 가능, 실패는 실패
|
위의 두 생성자를 사용하여 작업 구조를 만들 수 있습니다.
- 우선순위 매개변수는 작업의 우선순위를 나타냅니다.지정할 수 있으며 기본값은 nil입니다.
파라미터에 nil이 전달되면 Task.currentPriority가 사용됩니다. - 작동 매개변수에는 수행할 작업이 포함됩니다.폐쇄입니다.
위에서 만든 작업은 상위 작업이 없는 최상위 작업된다.
앞에서 설명한 구조화된 동시성에서와 같이 부모-자식과 같은 명시적인 계층 관계가 없기 때문입니다. 구조화되지 않은 병렬 처리그것은 ~라고 불린다.
이 구조화되지 않은 동시성에는 다음과 같은 특징이 있습니다.
- GroupTask 또는 async-let과 동일 원래 작업(또는 행위자)의 우선순위/특성을 상속합니다.하다.
- 수명 주기는 작업이 생성된 범위에 의해 결정되지 않습니다.
- 계획하거나 시작할 필요가 없습니다. 전화를 걸면 자동 예약하다.
- 작업을 호출한 함수가 비동기가 아닌 경우에도 호출 가능하다.
- 중단 및 오류는 자동으로 전달되지 않습니다.
구조적 동시성과는 반대로, 이들은 부품입니다. 직접 관리당신은해야합니다.
완료를 기다리거나 취소하려면 이 작업의 인스턴스를 유지해야 합니다.
이 작업 구조로 위의 예를 변경하면 오류가 수정되고 의도한 대로 작동합니다.
다음은 구조화되지 않은 병렬 처리가 런타임에 작동하는 방식을 시각적으로 나타낸 것입니다.
메인 스레드가 대기하는 동안 스레드를 포기 본질적으로 스레드는 서로 다른 코드를 실행합니다.
별도의 작업
위 방법으로 생성된 태스크의 경우, 태스크를 생성한 원래 태스크(또는 행위자)의 우선순위 및 특성을 상속합니다.받을 수 있는 성질을 가지고 있었습니다.
그러나 이러한 유전적 특성 없이 현재 작업(또는 행위자)과 독립적으로 새 작업을 생성하려는 경우.작업 유형에서 떨어져 있는 메서드를 사용하여 작업을 만들 수 있습니다.
|
공전 무선 전화 떨어져 있는(우선 사항: 작업 우선순위?, 작업: () 비동기 –> 성공) –> 일<성공, 실패> // 성공은 전송 가능, 실패는 절대 전송되지 않음
공전 무선 전화 떨어져 있는(우선 사항: 작업 우선순위?, 작업: () 비동기 던진다 –> 성공) –> 일<성공, 실패> // 성공은 전송 가능, 실패는 실패
|
이러한 개별 작업에는 다음과 같은 속성이 있습니다.
- 생성된 태스크의 실행은 태스크를 생성한 액터에게만 국한되지 않습니다.
- 생성된 태스크는 기존 태스크와 다른 우선순위로 실행될 수 있습니다.
위의 예에서 캐싱 절차를 추가해야 한다고 가정해 보겠습니다.
캐싱 로직은 상대적으로 낮은 우선순위로 동작할 수 있는 로직으로, 메인 스레드에서 실행 중인 현재 컨텍스트를 상속받을 필요가 없습니다.
이러한 경우 분리된 작업을 사용할 수 있습니다.
분리된 메서드는 runDetached라고 했으며 현재는 더 이상 사용되지 않습니다.
이 구조화되지 않은 동시성에서 구조화된 동시성을 활용할 수 있습니다.
|
일.떨어져 있는(우선 사항: .배경) {
작업 그룹과 함께(에서: 비어 있는.본인) { 그룹 ~ 안에
그룹.작업 추가 {writeToLocalCache(썸네일)}
그룹.작업 추가 { /* 실습 2 */ }
그룹.작업 추가 { /* 태스크 3 */ }
}
}
|
위 코드와 같이 구조화되지 않은 동시성 코드에 구조화된 동시성 코드를 추가하여 확장할 수 있습니다.
2. 구조화되지 않은 동시성으로 중단/실패
위에서 구조화되지 않은 병렬 처리용 구조적 병렬성과 대조 오류 시 직접 취소/전달 구현해야한다고 말했어
이러한 기능을 수행하기 위해서는 생성된 작업 유형에 대한 속성을 저장해야 합니다.
작업 유형 중단 방법사용 호출된 작업을 중단됨으로 표시당신은 할 수 있습니다.
작업 취소에 응답하지 않는 작업의 경우 이 메서드를 호출해도 아무런 효과가 없습니다.
다음 두 가지 방법을 사용하여 작업이 취소되었는지 확인할 수 있습니다.
- isCancelled: 작업이 취소되었는지 여부를 나타내는 멤버 변수 또는 유형 변수로 존재하는 부울 값입니다.
- checkCancellation() : 방법을 입력하고 작업이 취소된 경우 던지기 취소 오류 하다.
타입 변수와 타입 메소드의 경우 아래와 같이 태스크 완료 내에서 호출하여 태스크가 취소되었는지 확인할 수 있습니다.
|
일 {
// 시간이 1 걸리는 작업
누르다(“취소 여부: \(일.취소된다)”)
시도 일.확인취소()
// 시간이 걸리는 작업 2
}
|
던지기와 같이 던질 수 있는 메서드를 호출할 때 B. 방법 checkCancellation, 작업 유형이 변경됩니다.
이번 포스팅은 여기!
Actors와 Sendables에 대해 다루고 싶었는데 너무 많을 것 같아서 다음 포스팅에서 정리해보도록 하겠습니다.
읽어 주셔서 감사합니다!