苹果公司的多线程编程指南

需积分: 10 174 浏览量更新于2024-08-01 收藏 838KB PDF 举报

"苹果公司的线程编程指南，旨在帮助开发者理解和使用线程技术来优化程序性能。" 在多核处理器成为标准配置的时代，线程编程是优化应用性能的关键技术之一。苹果公司发布的这份《Threading Programming Guide》为Mac平台的开发者提供了关于线程编程的详细指导。线程允许应用程序同时执行多个任务，从而充分利用多核硬件的优势，提高系统效率，减少响应时间，提升用户体验。线程编程的核心概念包括以下几个方面： 1. **线程创建与管理**：创建线程是利用多核处理器的第一步。苹果的文档可能涵盖了使用API（如NSThread、NSOperationQueue或Dispatch Queues）创建和管理线程的方法，这些API简化了线程生命周期的控制。 2. **线程同步与通信**：为了防止多个线程同时访问共享资源导致的数据不一致，开发者需要掌握线程同步机制，如锁（NSLock、NSRecursiveLock）、信号量（NSCondition、NSConditionLock）以及GCD中的barrier dispatches等。 3. **线程优先级与调度**：理解线程优先级和调度策略对于优化性能至关重要。线程的优先级可以影响它们在CPU上的执行顺序，而调度队列（Serial或Concurrent）决定了任务的并发执行方式。 4. **线程安全的数据访问**：在多线程环境中，对共享数据的访问需要特别注意。线程安全的数据结构和API，如NSLocking协议实现的类，可以帮助开发者避免竞态条件和死锁。 5. **线程池管理**：线程池是一种优化资源利用率的技术，它避免了频繁地创建和销毁线程的开销。苹果可能讨论了如何有效地使用线程池，以及何时使用操作队列（NSOperationQueue）作为线程池的替代方案。 6. **性能优化**：文档会涉及如何通过合理分配工作负载、避免过度线程化和I/O阻塞来提升整体性能。这包括使用异步操作、避免线程间的上下文切换以及合理设定线程数量等。 7. **错误处理与调试**：线程编程中难免会出现问题，如死锁、活锁、资源争抢等。文档可能会提供调试线程问题的工具和技巧，如使用Instruments中的Thread Sanitizer或分析线程调用堆栈。 8. **内存管理与线程**：在多线程环境中，正确管理内存是至关重要的。苹果的自动引用计数（ARC）在多线程中的行为，以及如何确保线程安全的释放资源，都是开发者需要注意的点。 9. **最佳实践**：最后，这份指南可能会给出一些最佳实践，教导开发者如何设计健壮、高效的多线程应用程序，包括避免长时间运行的主线程任务，以及如何在保持性能的同时确保用户体验。苹果的《Threading Programming Guide》是Mac开发者的宝贵资源，它深入浅出地解释了线程编程的概念和技术，有助于开发者构建高性能、高并发的应用程序。

Threading Support

If you have existing code that uses threads, Mac OS X and iPhone OS provide several technologies for creating

threads in your applications. In addition, both systems also provide support for managing and synchronizing

the work that needs to be done on those threads. The following sections describe some of the key technologies

that you need to be aware of when working with threads in Mac OS X and iPhone OS.

Threading Packages

Although the underlying implementation mechanism for threads is Mach threads, you rarely (if ever) work

with threads at the Mach level. Instead, you usually use the more convenient POSIX API or one of its derivatives.

The Mach implementation does provide the basic features of all threads, however, including the preemptive

execution model and the ability to schedule threads so they are independent of each other.

Listing 2-2 lists the threading technologies you can use in your applications.

Table 1-2 Thread technologies

DescriptionTechnology

Cocoa implements threads using the NSThread class. Cocoa also provides methods

on NSObject for spawning new threads and executing code on already-running

threads. For more information, see “Using NSThread” (page 22) and “Using NSObject

to Spawn a Thread” (page 25).

Cocoa threads

POSIX threads provide a C-based interface for creating threads. If you are not writing

a Cocoa application, this is the best choice for creating threads. The POSIX interface

is relatively simple to use and offers ample flexibility for configuring your threads.

For more information, see “Using POSIX Threads” (page 24)

POSIX threads

Multiprocessing Services is a legacy C-based interface used by applications

transitioning from older versions of Mac OS. This technology is available in Mac OS

X only and should avoid anyway for any new development. Instead, you should use

the NSThread class or POSIX threads. For more information about this technology,

however, see Multiprocessing Services Programming Guide.

Multiprocessing

Services

At the application level, all threads behave in essentially the same way as on other platforms. After starting

a thread, the thread runs in one of three main states: running, ready, or blocked. If a thread is not currently

running, it is either blocked and waiting for input or it is ready to run but not scheduled to do so yet. The

thread continues moving back and forth among these states until it finally exits and moves to the terminated

state.

When you create a new thread, you must specify an entry-point function (or an entry-point method in the

case of Cocoa threads) for that thread. This entry-point function constitutes the code you want to run on the

thread. When the function returns, or when you terminate the thread explicitly, the thread stops permanently

and is reclaimed by the system. Because threads are relatively expensive to create in terms of memory and

time, it is therefore recommended that your entry point function do a significant amount of work or set up

a run loop to allow for recurring work to be performed.

Threading Support

CHAPTER 1

About Threaded Programming

For more information about the available threading technologies and how to use them, see “Thread

Management” (page 21).

Run Loops

A run loop is a piece of infrastructure used to manage events arriving asynchronously on a thread. A run loop

works by monitoring one or more event sources for the thread. As events arrive, the system wakes up the

thread and dispatches the events to the run loop, which then dispatches them to the handlers you specify.

If no events are present and ready to be handled, the run loop puts the thread to sleep.

You are not required to use a run loop with any threads you create but doing so can provide a better

experience for the user. Run loops make it possible to create long-lived threads that use a minimal amount

of resources. Because a run loop puts its thread to sleep when there is nothing to do, it eliminates the need

for polling, which wastes CPU cycles and prevents the processor itself from sleeping and saving power.

To configure a run loop, all you have to do is launch your thread, get a reference to the run loop object,

install your event handlers, and tell the run loop to run. The infrastructure provided by both Cocoa and

Carbon handles the configuration of the main thread’s run loop for you automatically. If you plan to create

long-lived secondary threads, however, you must configure the run loop for those threads yourself.

Details about run loops and examples of how to use them are provided in “Run Loops” (page 33).

Synchronization Tools

One of the hazards of threaded programming is resource contention among multiple threads. If multiple

threads try to use or modify the same resource at the same time, problems can occur. One way to alleviate

the problem is to eliminate the shared resource altogether and make sure each thread has its own distinct

set of resources on which to operate. When maintaining completely separate resources is not an option

though, you may have to synchronize access to the resource using locks, conditions, atomic operations, and

other techniques.

Locks provide a brute force form of protection for code that can be executed by only one thread at a time.

The most common type of lock is mutual exclusion lock, also known as a mutex. When a thread tries to

acquire a mutex that is currently held by another thread, it blocks until the lock is released by the other

thread. Several system frameworks provide support for mutex locks, although they are all based on the same

underlying technology. In addition, Cocoa provides several variants of the mutex lock to support different

types of behavior, such as recursion. For more information about the available types of locks, see “Locks” (page

58).

In addition to locks, the system provides support for conditions, which ensure the proper sequencing of tasks

within your application. A condition acts as a gatekeeper, blocking a given thread until the condition it

represents becomes true. When that happens, the condition releases the thread and allows it to continue.

The POSIX layer and Foundation framework both provide direct support for conditions. (If you use operation

objects, you can configure dependencies among your operation objects to sequence the execution of tasks,

which is very similar to the behavior offered by conditions.)

Although locks and conditions are very common in concurrent design, atomic operations are another way

to protect and synchronize access to data. Atomic operations offer a lightweight alternative to locks in

situations where you can perform mathematical or logical operations on scalar data types. Atomic operations

use special hardware instructions to ensure that modifications to a variable are completed before other

threads have a chance to access it.

Threading Support 15

CHAPTER 1

About Threaded Programming

For more information about the available synchronization tools, see “Synchronization Tools” (page 57).

Interthread Communication

Although a good design minimizes the amount of required communication, at some point, communication

between threads becomes necessary. (A thread’s job is to do work for your application, but if the results of

that job are never used, what good is it?) Threads may need to process new job requests or report their

progress to your application’s main thread. In these situations, you need a way to get information from one

thread to another. Fortunately, the fact that threads share the same process space means you have lots of

options for communication.

There are many ways to communicate between threads, each with its own advantages and disadvantages.

“Configuring Thread-Local Storage” lists the most common communication mechanisms you can use in Mac

OS X. (With the exception of message queues and Cocoa distributed objects, these technologies are also

available in iPhone OS.) The techniques in this table are listed in order of increasing complexity.

Table 1-3 Communication mechanisms

DescriptionMechanism

Cocoa applications support the ability to perform selectors directly on other threads.

This capability means that one thread can essentially execute a method on any other

thread. Because they are executed in the context of the target thread, messages sent

this way are automatically serialized on that thread. For information about input

sources, see “Cocoa Perform Selector Sources” (page 36).

Direct messaging

Another simple way to communicate information between two threads is to use a

global variable, shared object, or shared block of memory. Although shared variables

are fast and simple, they are also more fragile than direct messaging. Shared variables

must be carefully protected with locks or other synchronization mechanisms to ensure

the correctness of your code. Failure to do so could lead to race conditions, corrupted

data, or crashes.

Global variables,

shared memory,

and objects

Conditions are a synchronization tool that you can use to control when a thread

executes a particular portion of code. You can think of conditions as gate keepers,

letting a thread run only when the stated condition is met. For information on how

to use conditions, see “Using Conditions” (page 71).

Conditions

A custom run loop source is one that you set up to receive application-specific

messages on a thread. Because they are event driven, run loop sources put your thread

to sleep automatically when there is nothing to do, which improves your thread’s

efficiency. For information about run loops and run loop sources, see “Run Loops” (page

33).

Run loop sources

Port-based communication is a more elaborate way to communication between two

threads, but it is also a very reliable technique. More importantly, ports and sockets

can be used to communicate with external entities, such as other processes and

services. For efficiency, ports are implemented using run loop sources, so your thread

sleeps when there is no data waiting on the port. For information about run loops

and about port-based input sources, see “Run Loops” (page 33).

Ports and sockets

Threading Support

CHAPTER 1

About Threaded Programming

DescriptionMechanism

Multiprocessing Services defines a first-in, first-out (FIFO) queue abstraction for

managing incoming and outgoing data. Although message queues are simple and

convenient, they are not as efficient as some other communications techniques. For

more information about how to use message queues, see Multiprocessing Services

Programming Guide.

Message queues

Distributed objects is a Cocoa technology that provides a high-level implementation

of port-based communications. Although it is possible to use this technology for

interthread communication, doing so is highly discouraged because of the amount

of overhead it incurs. Distributed objects is much more suitable for communicating

with other processes, where the overhead of going between processes is already high.

For more information, see Distributed Objects Programming Topics.

Cocoa distributed

objects

Design Tips

The following sections offer guidelines to help you implement threads in a way that ensures the correctness

of your code. Some of these guidelines also offer tips for achieving better performance with your own

threaded code. As with any performance tips, you should always gather relevant performance statistics

before, during, and after you make changes to your code.

Avoid Creating Threads Explicitly

Writing thread-creation code manually is tedious and potentially error-prone and you should avoid it whenever

possible. Mac OS X and iPhone OS provide implicit support for concurrency through other APIs. Rather than

create a thread yourself, consider using asynchronous APIs, GCD, or operation objects to do the work. These

technologies do the thread-related work behind the scenes for you and are guaranteed to do it correctly. In

addition, technologies such as GCD and operation objects are designed to manage threads much more

efficiently than your own code ever could by adjusting the number of active threads based on the current

system load. For more information about GCD and operation objects, see Concurrency Programming Guide.

Keep Your Threads Reasonably Busy

If you decide to create and manage threads manually\f, remember that threads consume precious system

resources. You should do your best to make sure that any tasks you assign to threads are reasonably long-lived

and productive. At the same time, you should not be afraid to terminate threads that are spending most of

their time idle. Threads use a nontrivial amount of memory, some of it wired, so releasing an idle thread not

only helps reduce your application’s memory footprint, it also frees up more physical memory for other

system processes to use.

Design Tips 17

CHAPTER 1

About Threaded Programming

Important: Before you start terminating idle threads, you should always record a set of baseline measurements

of your applications current performance. After trying your changes, take additional measurements to verify

that the changes are actually improving performance, rather than hurting it.

Avoid Shared Data Structures

The simplest and easiest way to avoid thread-related resource conflicts is to give each thread in your program

its own copy of whatever data it needs. Parallel code works best when you minimize the communication

and resource contention among your threads.

Creating a multithreaded application is hard. Even if you are very careful and lock shared data structures at

all the right junctures in your code, your code may still be semantically unsafe. For example, your code could

run into problems if it expected shared data structures to be modified in a specific order. Changing your

code to a transaction-based model to compensate could subsequently negate the performance advantage

of having multiple threads. Eliminating the resource contention in the first place often results in a simpler

design with excellent performance.

Threads and Your User Interface

If your application has a graphical user interface, it is recommended that you receive user-related events and

initiate interface updates from your application’s main thread. This approach helps avoid synchronization

issues associated with handling user events and drawing window content. Some frameworks, such as Cocoa,

generally require this behavior, but even for those that do not, keeping this behavior on the main thread

has the advantage of simplifying the logic for managing your user interface.

There are a few notable exceptions where it is advantageous to perform graphical operations from other

threads. For example, the QuickTime API includes a number of operations that can be performed from

secondary threads, including opening movie files, rendering movie files, compressing movie files, and

importing and exporting images. Similarly, in Carbon and Cocoa you can use secondary threads to create

and process images and perform other image-related calculations. Using secondary threads for these operations

can greatly increase performance. If you are not sure about a particular graphical operation though, plan on

doing it from your main thread.

For more information about QuickTime thread safety, see Technical Note TN2125: “Thread-Safe Programming

in QuickTime.” For more information about Cocoa thread safety, see “Thread Safety Summary” (page 75).

For more information about drawing in Cocoa, see Cocoa Drawing Guide.

Be Aware of Thread Behaviors at Quit Time

A process runs until all nondetached threads have exited. By default, only the application’s main thread is

created as nondetached, but you can create other threads that way as well. When the user quits an application,

it is usually considered appropriate behavior to terminate all detached threads immediately, because the

work done by detached threads is considered optional. If your application is using background threads to

save data to disk or do other critical work, however, you may want to create those threads as nondetached

to prevent the loss of data when the application exits.

Design Tips

CHAPTER 1

About Threaded Programming

剩余85页未读，继续阅读

tozheng

粉丝: 12
资源: 2

苹果公司的多线程编程指南

Threading Programming Guide中文版

多线程编程指南

com.harmonyos.exception.WebViewRenderingException.md

基于STM32f103的重力点阵屏

com.pureharmony.exception.DisplayFailureException解决方案(亲测可用).md

一个基于Bootstrap框架的个人秀项目

com.pureharmony.exception.ImageProcessingException解决方案(亲测可用).md

com.harmonyos.exception.AppCrashException(解决方案).md

EaseUSDataRecoveryWizard v2.2.1.1技术级终身版.txt

com.harmonyos4.exception.BatteryDepletionException解决方案(亲测可用).md

最新资源