Thread Safety Summary, Threading Programming Guide 번역

iOS Developer Library/Guides 2013. 9. 21. 18:40

Intorduction | About Threaded Programming | Thread Management | Run Loops
Synchronization | Thread Safety Summary | Glossary

본 페이지는 Threading Programming Guide 문서의 Thread Safety Summary 부분을 번역해 놓은 페이지 입니다. 발 번역이라 이상한 부분이 있을 수 있습니다. 발견즉시 댓글을 달아 주세요.


Thread Safety Summary
스레드로부터의 안전성 요약

This appendix describes the high-level thread safety of some key frameworks in OS X and iOS. The information in this appendix is subject to change.

이 부록에서는 OS X 및 IOS의 몇 가지 핵심 프레임 워크의 상위 레벨 스레드로부터의 안전성을 설명합니다. 이 부록의 내용은 변경 될 수 있습니다.

Cocoa

Guidelines for using Cocoa from multiple threads include the following:
여러 스레드에서 코코아를 사용하기위한 지침은 다음과 같습니다 :

  • Immutable objects are generally thread-safe. Once you create them, you can safely pass these objects to and from threads. On the other hand, mutable objects are generally not thread-safe. To use mutable objects in a threaded application, the application must synchronize appropriately. For more information, see“Mutable Versus Immutable.”
    불변의 객체는 일반적으로 스레드 안전합니다. 당신이 그들을 생성되면, 당신은 안전과 스레드에서 이러한 개체를 전달할 수 있습니다. 반면에, 변경 가능한 개체는 일반적으로 스레드로부터 안전하지 않습니다.스레드 응용 프로그램에서 변경 가능 오브젝트를 사용하려면 응용 프로그램이 적절하게 동기화해야합니다. 자세한 내용은 "변경 가능한 불변의 대 (对)"을 참조하십시오.

  • Many objects deemed “thread-unsafe” are only unsafe to use from multiple threads. Many of these objects can be used from any thread as long as it is only one thread at a time. Objects that are specifically restricted to the main thread of an application are called out as such.
    인정 많은 개체가 "스레드 안전하지 않은"여러 스레드에서 사용하는 경우에만 안전합니다. 그것은 한 번에 하나의 스레드로 이러한 개체의 대부분은만큼 모든 스레드에서 사용할 수 있습니다. 특히 응용 프로그램의 주 스레드로 제한되는 개체는 다음과 같은 최신이라고합니다.

  • The main thread of the application is responsible for handling events. Although the Application Kit continues to work if other threads are involved in the event path, operations can occur out of sequence.
    응용 프로그램의 주 스레드가 이벤트를 처리 할 책임이 있습니다. 응용 프로그램 키트는 다른 스레드가 이벤트 경로에 관여하는 경우 계속 작동하지만, 작업 순서에서 발생할 수 있습니다.

  • If you want to use a thread to draw to a view, bracket all drawing code between the lockFocusIfCanDraw and unlockFocus methods of NSView.
    당신이 lockFocusIfCanDraw 사이보기, 브라켓 모든 그리기 코드에 그리 NSView의 방법을 unlockFocus 스레드를 사용합니다.

  • To use POSIX threads with Cocoa, you must first put Cocoa into multithreaded mode. For more information, see “Using POSIX Threads in a Cocoa Application.”
    코코아와 POSIX 스레드를 사용하려면 먼저 멀티 스레드 모드로 코코아를 넣어해야합니다. 자세한 내용은 "코코아 응용 프로그램에서 POSIX 스레드 사용"을 참조하십시오.

Foundation Framework Thread Safety

기반 프레임 워크 스레드로부터의 안전성

There is a misconception that the Foundation framework is thread-safe and the Application Kit framework is not. Unfortunately, this is a gross generalization and somewhat misleading. Each framework has areas that are thread-safe and areas that are not thread-safe. The following sections describe the general thread safety of the Foundation framework.

재단 프레임 워크는 스레드로부터 안전하고 응용 프로그램 키트 프레임 워크는 아니라고 오해가있다. 불행하게도,이 총 일반화 다소 오해의 소지가. 각 프레임 워크는 스레드 안전 및 스레드 안전하지 않은 영역입니다 영역이 있습니다.다음 섹션에서는 재단 프레임 워크의 일반적인 스레드로부터의 안전성을 설명합니다.

Thread-Safe Classes and Functions
스레드 안전 클래스와 함수

The following classes and functions are generally considered to be thread-safe. You can use the same instance from multiple threads without first acquiring a lock.

다음과 같은 클래스와 함수는 일반적으로 스레드 안전한 것으로 간주됩니다. 먼저 잠금을 획득하지 않고 여러 스레드에서 동일한 인스턴스를 사용할 수 있습니다.

Thread-Unsafe Classes
스레드 안전하지 않은 클래스

The following classes and functions are generally not thread-safe. In most cases, you can use these classes from any thread as long as you use them from only one thread at a time. Check the class documentation for additional details.

다음과 같은 클래스와 함수는 thread 세이프가 일반적으로하지 않습니다. 당신은 한 번에 하나의 스레드에서 그들을 사용할 때 대부분의 경우에, 당신은만큼 모든 스레드에서 이러한 클래스를 사용할 수 있습니다. 자세한 내용에 대한 클래스 설명서를 참조하십시오.

Note that although NSSerializer, NSArchiver, NSCoder, and NSEnumerator objects are themselves thread-safe, they are listed here because it is not safe to change the data objects wrapped by them while they are in use. For example, in the case of an archiver, it is not safe to change the object graph being archived. For an enumerator, it is not safe for any thread to change the enumerated collection.

NSSerializer, NSArchiver, NSCoder 및 NSEnumerator 객체가 스레드 안전 자체 있지만 그것은 그들이 사용하는 동안 그들에 의해 래핑 된 데이터 오브젝트를 변경하는 것이 안전하지 않기 때문에, 그들은 여기에 나열되어 있습니다. 예를 들어, 아카이브의 경우는 아카이브되는 개체 그래프를 변경하는 것은 안전하지 않습니다.열거를 들어, 열거 컬렉션을 변경하는 모든 스레드에 안전하지 않습니다.

Main Thread Only Classes
메인 스레드 클래스 만

The following class must be used only from the main thread of an application.
다음 클래스는 응용 프로그램의 주 스레드에서 사용해야합니다.

  • NSAppleScript

Mutable Versus Immutable
가변 불변의 대

Immutable objects are generally thread-safe; once you create them, you can safely pass these objects to and from threads. Of course, when using immutable objects, you still need to remember to use reference counts correctly. If you inappropriately release an object you did not retain, you could cause an exception later.

불변의 객체는 일반적으로 스레드 안전, 일단 당신이 그들을 만들, 당신은 안전과 스레드에서 이러한 개체를 전달할 수 있습니다. 물론, 불변의 객체를 사용하는 경우, 당신은 여전히 ​​올바르게 참조 카운트를 사용하는 기억해야합니다. 당신이 부적절 당신이 보유하지 않은 개체를 해제하면, 나중에 예외가 발생할 수 있습니다.

Mutable objects are generally not thread-safe. To use mutable objects in a threaded application, the application must synchronize access to them using locks. (For more information, see “Atomic Operations”). In general, the collection classes (for example, NSMutableArray, NSMutableDictionary) are not thread-safe when mutations are concerned. That is, if one or more threads are changing the same array, problems can occur. You must lock around spots where reads and writes occur to assure thread safety.

변경 가능한 개체는 일반적으로 스레드로부터 안전하지 않습니다.스레드 응용 프로그램에서 변경 가능한 개체를 사용하려면 응용 프로그램은 그들이 잠금을 사용하여 액세스를 동기화해야합니다. (자세한 내용은 "원자 작업"참조). 돌연변이가 우려되는 경우, 일반적으로 컬렉션 클래스 (예를 들어, NSMutableArray, NSMutableDictionary)는 스레드로부터 안전하지 않습니다. 즉, 하나 이상의 스레드가 동일한 배열을 변경하는 경우 문제가 발생할 수 있습니다. 당신이 읽고 스레드로부터의 안전성을 보장하기 위해 발생 기록 반점 주위 잠 가야합니다.

Even if a method claims to return an immutable object, you should never simply assume the returned object is immutable. Depending on the method implementation, the returned object might be mutable or immutable. For example, a method with the return type of NSString might actually return anNSMutableString due to its implementation. If you want to guarantee that the object you have is immutable, you should make an immutable copy.

방법은 불변의 객체를 반환 주장하더라도, 당신은 단순히 반환 된 객체는 불변이라고 가정해서는 안됩니다.메서드 구현에 따라 반환 된 개체는 변경할 수 또는 불변 수 있습니다. 예를 들어,있는 NSString의 반환 형식 메서드를 실제로 구현으로 인해 anNSMutableString를 반환 할 수 있습니다. 당신은 당신이 객체는 불변하다는 것을 보장하려는 경우, 당신은 불변의 복사본을 만들어야합니다.

Reentrancy
재

Reentrancy is only possible where operations “call out” to other operations in the same object or on different objects. Retaining and releasing objects is one such “call out” that is sometimes overlooked.

작업이 동일한 개체 또는 다른 개체에 다른 작업에 "불러"여기서 재진입에만 가능합니다. 유지와 개체를 해제하는 것은 종종 간과 하나의 "통화 중"입니다.

The following table lists the portions of the Foundation framework that are explicitly reentrant. All other classes may or may not be reentrant, or they may be made reentrant in the future. A complete analysis for reentrancy has never been done and this list may not be exhaustive.

다음 표는 명시 적으로 재진입 재단 프레임 워크의 부분을 보여줍니다. 다른 모든 클래스 또는 재진입 될 수도 있고 그렇지 않을 수도 있습니다, ​​또는 그들은 미래에 재진입 할 수 있습니다. 재에 대한 완전한 분석을 수행 한 적이 있으며이 목록은 완전한되지 않을 수 있습니다.

Class Initialization
클래스 초기화

The Objective-C runtime system sends an initialize message to every class object before the class receives any other messages. This gives the class a chance to set up its runtime environment before it’s used. In a multithreaded application, the runtime guarantees that only one thread—the thread that happens to send the first message to the class—executes the initialize method. If a second thread tries to send messages to the class while the first thread is still in the initializemethod, the second thread blocks until the initialize method finishes executing. Meanwhile, the first thread can continue to call other methods on the class. Theinitialize method should not rely on a second thread calling methods of the class; if it does, the two threads become deadlocked.

클래스가 다른 메시지를 수신하기 전에 오브젝티브-C 런타임 시스템은 모든 클래스 객체에 초기화 메시지를 보냅니다. 이 클래스에게 그것이 사용되기 전에 자사의 런타임 환경을 설정 할 수있는 기회를 제공합니다.다중 스레드 응용 프로그램에서 런타임은 단 하나의 스레드에 첫 번째 메시지를 보내려면 어떻게 스레드 초기화 메소드를 클래스 - 실행하는 보장합니다. 첫 번째 스레드가 initializemethod에있는 동안 두 번째 스레드는 클래스에 메시지를 보내려고하면 초기화 방법까지 두 번째 스레드 블록은 실행을 종료합니다. 한편, 첫 번째 스레드는 클래스의 다른 메서드를 호출을 계속할 수 있습니다. 메서드는 클래스의 메서드를 호출하는 두 번째 스레드에 의존해서는 안 Theinitialize, 그것은 않는 경우, 두 개의 스레드가 교착 상태가됩니다.

Due to a bug in OS X version 10.1.x and earlier, a thread could send messages to a class before another thread finished executing that class’s initialize method. The thread could then access values that have not been fully initialized, perhaps crashing the application. If you encounter this problem, you need to either introduce locks to prevent access to the values until after they are initialized or force the class to initialize itself before becoming multithreaded.

다른 스레드가 해당 클래스의 initialize 메소드 실행을 완료하기 전에 OS X의 이전 버전 10.1.x과 버그로 인해 스레드는 클래스에 메시지를 보낼 수 있습니다.스레드는 완전히 아마 응용 프로그램 충돌, 초기화되지 않은 값을 액세스 할 수 있습니다. 이 문제가 발생하는 경우, 당신은 하나가 초기화 할 때까지 값에 대한 액세스를 방지하거나 클래스가 다중 스레드가되기 전에 자신을 초기화하도록하는 잠금을 도입 할 필요가있다.

Autorelease Pools

Each thread maintains its own stack of NSAutoreleasePool objects. Cocoa expects there to be an autorelease pool always available on the current thread’s stack. If a pool is not available, objects do not get released and you leak memory. An NSAutoreleasePool object is automatically created and destroyed in the main thread of applications based on the Application Kit, but secondary threads (and Foundation-only applications) must create their own before using Cocoa. If your thread is long-lived and potentially generates a lot of autoreleased objects, you should periodically destroy and create autorelease pools (like the Application Kit does on the main thread); otherwise, autoreleased objects accumulate and your memory footprint grows. If your detached thread does not use Cocoa, you do not need to create an autorelease pool.

각 스레드는 NSAutoreleasePool 객체 자체의 스택을 유지합니다. 코코아는 현재 스레드의 스택에 항상 사용할 수 autorelease를 풀 수있을 것으로 기대하고있다. 풀을 사용할 수없는 경우 개체가 해제하면 메모리 누수가되지 않습니다.NSAutoreleasePool 객체는 자동으로 생성하고 응용 프로그램 키트를 기반으로 응용 프로그램의 주 스레드에서 파괴하지만 보조 스레드 (및 기초 전용 응용 프로그램)는 코코아를 사용하기 전에 자신을 작성해야합니다. 귀하의 스레드가 오래 지속하고 잠재적 autoreleased 객체를 많이 생성하는 경우, 당신은 정기적으로 파괴하고 autorelease를 풀 (응용 프로그램 키트 같은 주 스레드에서 수행)을 생성해야한다, 그렇지 않으면 autoreleased 개체를 축적하고 메모리 풋 프린트가 증가합니다. 귀하의 분리 된 스레드가 코코아를 사용하지 않는 경우, 당신은 autorelease를 풀을 만들 필요가 없습니다.

Run Loops

Every thread has one and only one run loop. Each run loop, and hence each thread, however, has its own set of input modes that determine which input sources are listened to when the run loop is run. The input modes defined in one run loop do not affect the input modes defined in another run loop, even though they may have the same name.

모든 스레드가 하나만 실행 된 루프가 있습니다. 따라서 각 실행 루프, 각 스레드는하지만, 입력 소스가 실행 된 루프가 실행될 때 경청하는 결정 입력 모드의 그것의 자신의 세트가있다. 하나의 실행 루프에서 정의 된 입력 모드는 같은 이름을 가질 수 있더라도, 다른 실행 루프에서 정의 된 입력 모드에 영향을주지 않습니다.

The run loop for the main thread is automatically run if your application is based on the Application Kit, but secondary threads (and Foundation-only applications) must run the run loop themselves. If a detached thread does not enter the run loop, the thread exits as soon as the detached method finishes executing.

메인 스레드의 실행 루프는 응용 프로그램이 응용 프로그램 키트를 기반으로하는 경우 자동으로 실행되지만, 보조 스레드 (및 기초 전용 응용 프로그램)이 실행 루프 자체를 실행해야합니다.분리 된 스레드가 실행 된 루프를 입력하지 않으면 즉시 분리 방법으로 스레드가 종료 실행이 완료됩니다.

Despite some outward appearances, the NSRunLoop class is not thread safe. You should call the instance methods of this class only from the thread that owns it.

일부 외부 외관에도 불구하고, NSRunLoop 클래스는 스레드로부터 안전하지 않습니다. 당신은 그것을 소유하는 스레드에서이 클래스의 인스턴스 메서드를 호출해야합니다.

Application Kit Framework Thread Safety

The following sections describe the general thread safety of the Application Kit framework.
다음 섹션에서는 응용 프로그램 키트 프레임 워크의 일반적인 스레드로부터의 안전성을 설명합니다.

Thread-Unsafe Classes

The following classes and functions are generally not thread-safe. In most cases, you can use these classes from any thread as long as you use them from only one thread at a time. Check the class documentation for additional details.

다음과 같은 클래스와 함수는 thread 세이프가 일반적으로하지 않습니다. 당신은 한 번에 하나의 스레드에서 그들을 사용할 때 대부분의 경우에, 당신은만큼 모든 스레드에서 이러한 클래스를 사용할 수 있습니다. 자세한 내용에 대한 클래스 설명서를 참조하십시오.

Main Thread Only Classes

The following classes must be used only from the main thread of an application.

Window Restrictions
창 제한

You can create a window on a secondary thread. The Application Kit ensures that the data structures associated with a window are deallocated on the main thread to avoid race conditions. There is some possibility that window objects may leak in an application that deals with a lot of windows concurrently.

당신은 보조 스레드에서 창을 만들 수 있습니다.응용 프로그램 키트 창에 연결된 데이터 구조가 경쟁 조건을 피하기 위해 메인 스레드에 할당이 해제되어 있는지 확인합니다. Window 개체가 동시에 창을 많이 다루고있는 응용 프로그램에서 누수 될 수있는 몇 가지 가능성이 있습니다.

You can create a modal window on a secondary thread. The Application Kit blocks the calling secondary thread while the main thread runs the modal loop.

당신은 보조 스레드에서 모달 창을 만들 수 있습니다.주 스레드가 모달 루프를 실행하는 동안 응용 프로그램 키트 호출 보조 스레드를 차단합니다.

Event Handling Restrictions
이벤트 처리 제한

The main thread of the application is responsible for handling events. The main thread is the one blocked in the run method of NSApplication, usually invoked in an application’s main function. While the Application Kit continues to work if other threads are involved in the event path, operations can occur out of sequence. For example, if two different threads are responding to key events, the keys could be received out of order. By letting the main thread process events, you achieve a more consistent user experience. Once received, events can be dispatched to secondary threads for further processing if desired.

응용 프로그램의 주 스레드가 이벤트를 처리 할 책임이 있습니다.주 스레드는 일반적으로 응용 프로그램의 주 기능에서 호출 NSApplication의 run 메소드에 블록 하나입니다. 응용 프로그램 키트는 다른 스레드가 이벤트 경로에 관여하는 경우 작업을 계속하는 동안, 작업 순서에서 발생할 수 있습니다. 두 개의 서로 다른 스레드가 키 이벤트에 응답하는 경우 예를 들어, 키 순서가 수신 될 수 있습니다.메인 스레드 프로세스 이벤트시키는 것으로, 좀 더 일관성있는 사용자 경험을 얻을 수 있습니다. 일단 받아 원하는 경우 이벤트는 추가 처리를 위해 보조 스레드에 파견 할 수있다.

You can call the postEvent:atStart: method of NSApplication from a secondary thread to post an event to the main thread’s event queue. Order is not guaranteed with respect to user input events, however. The main thread of the application is still responsible for handling events in the event queue.

메인 스레드의 이벤트 큐에 이벤트를 게시하는 보조 스레드에서 NSApplication의 방법 : atStart : 당신이 postEvent를 호출 할 수 있습니다. 순서는하지만, 사용자 입력 이벤트에 대해 보증하지 않습니다. 응용 프로그램의 주 스레드는 여전히 이벤트 큐에서 이벤트를 처리하는 책임이 있습니다.

Drawing Restrictions
제한 그리기

The Application Kit is generally thread-safe when drawing with its graphics functions and classes, including the NSBezierPath and NSString classes. Details for using particular classes are described in the following sections. Additional information about drawing and threads is available in Cocoa Drawing Guide.

NSBezierPath하고있는 NSString 클래스를 포함한 그래픽 함수와 클래스로 그릴 때 응용 프로그램 키트는 일반적으로 스레드 안전합니다. 특정 클래스를 사용하기위한 자세한 내용은 다음 절에서 설명합니다. 그림과 스레드에 대한 추가 정보는 코코아 드로잉 가이드에서 사용할 수 있습니다.

NSView Restrictions

The NSView class is generally not thread-safe. You should create, destroy, resize, move, and perform other operations on NSView objects only from the main thread of an application. Drawing from secondary threads is thread-safe as long as you bracket drawing calls with calls to lockFocusIfCanDraw and unlockFocus.

NSView 클래스는 일반적으로 스레드로부터 안전하지 않습니다. 당신은 생성, 파괴, 크기 조정, 이동, 만 응용 프로그램의 주 스레드에서 NSView 개체에 대한 다른 작업을 수행해야합니다. 당신 브라켓 도면 lockFocusIfCanDraw 및 unlockFocus에 대한 호출과 호출로 보조 스레드에서 그리기만큼 스레드 안전합니다.

If a secondary thread of an application wants to cause portions of the view to be redrawn on the main thread, it must not do so using methods like display,setNeedsDisplay:, setNeedsDisplayInRect:, or setViewsNeedDisplay:. Instead, it should send a message to the main thread or call those methods using the performSelectorOnMainThread:withObject:waitUntilDone: method instead.

, setNeedsDisplayInRect : 또는 setViewsNeedDisplay 응용 프로그램의 보조 스레드는 메인 스레드에서 다시 그려야 할 뷰의 일부를 일으킬하고자하는 경우, 그것은 디스플레이, setNeedsDisplay과 같은 방법을 사용하여 그렇게하지해야합니다. 대신 주 스레드에 메시지를 보내야하거나 performSelectorOnMainThread를 사용하여 해당 메서드를 호출 : withObject : waitUntilDone 방법 : 대신.

The view system’s graphics states (gstates) are per-thread. Using graphics states used to be a way to achieve better drawing performance over a single-threaded application but that is no longer true. Incorrect use of graphics states can actually lead to drawing code that is less efficient than drawing in the main thread.

뷰 시스템의 그래픽 상태 (gstates)는 당 스레드 수 있습니다. 그래픽을 사용하면 더 나은 그리기 단일 스레드 응용 프로그램을 통해 성능을하지만 더 이상 그렇지 않습니다를 달성하는 방법이 사용 말한다. 그래픽 상태의 잘못된 사용은 실제로 메인 스레드에서 그리기보다 효율적인 그리기 코드로 이어질 수 있습니다.

NSGraphicsContext Restrictions
NSGraphicsContext 제한

The NSGraphicsContext class represents the drawing context provided by the underlying graphics system. Each NSGraphicsContext instance holds its own independent graphics state: coordinate system, clipping, current font, and so on. An instance of the class is automatically created on the main thread for eachNSWindow instance. If you do any drawing from a secondary thread, a new instance of NSGraphicsContext is created specifically for that thread.

NSGraphicsContext 클래스는 기본 그래픽 시스템에서 제공하는 그리기 컨텍스트를 나타냅니다. 그래서 좌표계, 클리핑, 현재의 글꼴 및 각 NSGraphicsContext 인스턴스는 독립적 인 그래픽 상태를 보유하고 있습니다.클래스의 인스턴스가 자동으로 eachNSWindow 인스턴스의 주 스레드에서 생성됩니다. 당신이 보조 스레드에서 모든 드로잉 작업을 수행 할 경우, NSGraphicsContext의 새 인스턴스가 해당 스레드를 위해 특별히 만들어집니다.

If you do any drawing from a secondary thread, you must flush your drawing calls manually. Cocoa does not automatically update views with content drawn from secondary threads, so you need to call the flushGraphics method of NSGraphicsContext when you finish your drawing. If your application draws content from the main thread only, you do not need to flush your drawing calls.

당신이 보조 스레드에서 어떤 도면을 할 경우, 당신은 당신의 그림이 전화에 수동으로 세척해야합니다. 코코아 자동으로 보조 스레드에서 그려진 내용으로 뷰를 업데이트하지 않습니다, ​​그래서 당신은 당신의 그림을 완성 할 때 NSGraphicsContext의 flushGraphics 메서드를 호출해야합니다. 응용 프로그램은 메인 스레드에서 콘텐츠를 그리는 경우에, 당신은 당신의 드로잉 호출을 세척 할 필요가 없습니다.

NSImage Restrictions

One thread can create an NSImage object, draw to the image buffer, and pass it off to the main thread for drawing. The underlying image cache is shared among all threads. For more information about images and how caching works, see Cocoa Drawing Guide.

하나의 스레드는 NSImage 개체를 만들고 이미지 버퍼에 그려 도면의 주요 스레드에 전원을 전달할 수 있습니다.기본 이미지 캐시는 모든 스레드간에 공유됩니다. 작품을 캐싱 이미지와 방법에 대한 자세한 내용은 코코아 드로잉 설명서를 참조하십시오.

Core Data Framework

The Core Data framework generally supports threading, although there are some usage caveats that apply. For information on these caveats, see “Concurrency with Core Data” in Core Data Programming Guide.

적용되는 몇 가지 사용법주의 사항이 있지만 코어 데이터 프레임 워크는 일반적으로 스레딩 지원합니다. 이러한주의 사항에 대한 자세한 내용은 코어 데이터 프로그래밍 가이드의 "코어 데이터 동시성"을 참조하십시오.

Core Foundation

Core Foundation is sufficiently thread-safe that, if you program with care, you should not run into any problems related to competing threads. It is thread-safe in the common cases, such as when you query, retain, release, and pass around immutable objects. Even central shared objects that might be queried from more than one thread are reliably thread-safe.

핵심 기초는 충분히주의 당신이 프로그램을하는 경우, 당신은 경쟁 스레드 관련 문제로 실행하지 않아야하는 스레드 안전합니다. 그런 당신은 쿼리 할 때, 유지 릴리스 및 불변의 주위에 통과, 일반적인 경우에 스레드 안전합니다. 하나 이상의 스레드에서 쿼리 할 수도 중앙 공유 객체 안정적으로 스레드 안전합니다.

Like Cocoa, Core Foundation is not thread-safe when it comes to mutations to objects or their contents. For example, modifying a mutable data or mutable array object is not thread-safe, as you might expect, but neither is modifying an object inside of an immutable array. One reason for this is performance, which is critical in these situations. Moreover, it is usually not possible to achieve absolute thread safety at this level. You cannot rule out, for example, indeterminate behavior resulting from retaining an object obtained from a collection. The collection itself might be freed before the call to retain the contained object is made.

이 개체 또는 해당 내용에 대한 돌연변이에 관해서는 코코아와 마찬가지로, 코어 재단은 스레드로부터 안전하지 않습니다. 예를 들어, 가변 데이터 또는 가변 배열 객체는 예상대로, 아니 스레드로부터 안전 수정하지만, 둘 다 불변의 배열의 내부 개체를 수정하지 않습니다. 이것에 대한 이유 중 하나는 이러한 상황에서 중요 한 성능입니다. 또한, 그것은이 수준에서 절대 스레드 안전을 달성하는 것이 불가능합니다. 당신은 예를 들어, 컬렉션에서 취득 된 객체를 유지 인한 불확실한 행동을 배제 할 수 없다. 포함 된 객체를 유지하는 호출이 이루어지기 전에 컬렉션 자체가 해제 될 수 있습니다.

In those cases where Core Foundation objects are to be accessed from multiple threads and mutated, your code should protect against simultaneous access by using locks at the access points. For instance, the code that enumerates the objects of a Core Foundation array should use the appropriate locking calls around the enumerating block to protect against someone else mutating the array.

코어 파운데이션 객체가 여러 스레드에서 액세스하고 변이 할 수있다 이러한 경우, 귀하의 코드는 액세스 포인트에서 잠금을 사용하여 동시 액세스로부터 보호해야합니다. 예를 들어, 코어 기반 배열의 개체를 열거 코드는 배열을 돌연변이 다른 사람을 방지하기 위해 열거 블록 주위에 적절한 잠금 호출을 사용합니다.

저작자표시 비영리 변경금지

'iOS Developer Library > Guides' 카테고리의 다른 글

Synchronization, Threading Programming Guide 번역  (0) 2013.09.21
Run Loops, Threading Programming Guide 번역  (0) 2013.09.21
Thread Management, Threading Programming Guide 번역  (2) 2013.09.21
About Threaded Programming, Threading Programming Guide 번역  (0) 2013.09.21
Intorduction, Threading Programming Guide 번역  (1) 2013.09.21
Posted by 창업자닉군
,

티스토리툴바