This is the sixth day of my participation in the August More text Challenge. For details, see:August is more challenging

Write in the front: the exploration of the underlying principles of iOS is my usual development and learning in the continuous accumulation of a step forward road. I hope it will be helpful for readers to record my journey of discovery.Copy the code

The directory is as follows:

1. Exploring the underlying principles of iOS alloc
2. Exploration of the underlying principles of iOS structure in vivo alignment
3. The nature of the object explored by iOS underlying principles & the underlying implementation of ISA
4. The underlying principles of the ISA-class (part 1)
5. The underlying principles of the ISA class (middle)
6. The underlying principles of isA-Class (part 2)
7. Exploring the nature of Runtime Runtime & Methods in iOS Underlying principles
8. Objc_msgSend explores the underlying principles of iOS
9. Runtime Runtime slow lookup process
10. Dynamic method resolution for exploring the underlying principles of iOS
11. IOS underlying principles to explore the message forwarding process
12. IOS Application loading principle
13. Application loading principle (2)
14. IOS underlying principle exploration class load
15. IOS Underlying principles to explore the classification of loading
16. Associated object for iOS underlying principle exploration
17. Exploration of iOS underlying principles of sorcerer KVC
18. Exploring the underlying principles of iOS — KVO Principles | more challenging in August
19. Exploration of the underlying principles of iOS rewrite KVO | August more text challenges
20. Exploring the underlying principles of iOS multithreading | more challenging in August

Summary column for the above

• Summary of the phase of iOS underlying principle exploration

preface

In the challenge of exploring the Underlying principles of iOS: Multithreading | August, we sorted out the life cycle of threads, the concept of threads and processes, and the relationship between them. And the meaning and principle of multithreading is also involved.

In fact, apple’s Thread programming guide has a section on alternatives to threads. Because one of the problems with creating your own threads is that they add uncertainty to the developer’s code. Threading is a relatively low-level and complex way to support concurrency in an application. If we don’t fully understand what we mean by our choices, it’s easy to run into problems in synchronization or timing that can range in severity from subtle behavior changes to application crashes and data corruption. So today we’ll take a look at GCD, the one we use the most, and explore the functions and queues of GCD.

The scheduling queue

The Grand Central Dispatch (GCD) Dispatch queue is a powerful tool for performing tasks. Scheduling queues allow you to execute arbitrary blocks of code asynchronously or synchronously, whether related to the caller. You can use scheduling queues to perform almost any task you used to perform on a separate thread. The advantage of scheduling queues is that they are easier to use than the corresponding threaded code and more efficient in performing these tasks.

About Scheduling Queues

Scheduling queues is a simple way to execute tasks asynchronously and concurrently in your application. One task is simply that your application needs to perform some work. For example, you can define a task to perform some calculation, create or modify a data structure, process some data read from a file, or any number of things. You can define a task by placing the corresponding code in a function or block object and adding it to the scheduling queue.

A scheduling queue is an object-like structure that manages the tasks you submit to it. All scheduling queues are first-in, first-out data structures. Therefore, the tasks you add to the queue are always started in the same order in which they were added. GCD automatically provides you with some scheduling queues, but you can create others for specific purposes. Table 3-1 lists the types of scheduling queues available to your application and how you can use them.

Table 3-1 Scheduling queue types

Scheduling queues offer several advantages over threads when adding concurrency to an application. The most immediate advantage is the simplicity of the work queue programming model. With threads, you must write code for the work to be performed and for the creation and management of the threads themselves. Scheduling queues lets you focus on the work you really want to perform without having to worry about thread creation and management. Instead, the system handles the creation and management of all threads for you. The advantage is that the system can manage threads more efficiently than any single application. The system can dynamically adjust the number of threads based on available resources and current system conditions. In addition,

Although you might think it would be difficult to rewrite code for scheduling queues, writing code for scheduling queues is often easier than writing code for threads. The key to writing code is to design tasks that are self-contained and can run asynchronously. (This is actually true for both threads and scheduled queues.) The advantage of scheduling queues, however, is predictability. If you have two tasks accessing the same shared resource but running on different threads, then either thread can modify the resource first, and you need to use a lock to ensure that both tasks do not modify the resource at the same time. With a schedule queue, you can add two tasks to a serial schedule queue to ensure that only one task modifs the resource at any given time.

While you are correct to point out that two tasks running in a serial queue will not run at the same time, you must remember that any concurrency provided by the threads is lost or significantly reduced if both threads acquire the lock at the same time. More importantly, the threading model requires the creation of two threads, which take up kernel space and user-space memory. Scheduling queues do not pay the same memory loss for their threads, and the threads they do use remain busy and do not block.

Some other key points to remember about scheduling queues include:

• Scheduling queues execute their tasks concurrently with other scheduling queues. Serialization of tasks is limited to tasks in a single scheduling queue.
• The system determines the total number of tasks to be performed at any given time. Therefore, an application with 100 tasks in 100 different queues may not perform all of these tasks at the same time (unless it has 100 or more valid kernels).
• Queue priorities are taken into account when selecting which new tasks to start. For information on how to set the priority of a serial queue, see Providing cleanup for queues.
• Tasks in a queue must be ready for execution when they are added to the queue. (If you have worked with Cocoa operation objects before, note that this behavior is different from that used by model operations.)
• A private schedule queue is an object of reference counting. In addition to keeping queues in your own code, note that a scheduling source can also be attached to a queue and increase its retention count. Therefore, you must ensure that all scheduling sources are cancelled and that all retention calls are balanced with appropriate release calls. For more information about preserving and releasing Queues, see Memory Management of Dispatch Queues. For more information about scheduling sources, see About Scheduling Sources.

Queue correlation technique

In addition to dispatching queues, Grand Central Dispatch offers a variety of techniques for using queues to help manage code. Table 3-2 lists these technologies and provides links to where you can find more information about them.

Table 3-2 Technologies for using scheduling queues

Use blocks to implement tasks

Block objects are a C-based language feature that you can use in C, objective-C, and C++ code. A block can easily define a separate unit of work. Although they look like function Pointers, blocks are actually represented by underlying data structures similar to objects, and are created and managed for you by the compiler. The compiler packages the code you provide (and any associated data) and wraps it into a form that can live in the heap and be passed around in your application.

One of the main advantages of blocks is their ability to use variables outside of their lexical scope. When you define a block in a function or method, that block in some ways acts as a traditional block of code. For example, a block can read the value of a variable defined in a parent scope. Block-accessed variables are copied into block data structures on the heap so that blocks can access them later. When blocks are added to the scheduling queue, these values must generally be kept in read-only format. However, synchronized blocks can also use a variable with the __block keyword to return data to the parent’s call scope.

You can declare blocks inline in your code using syntax similar to that used for function Pointers. The main difference between a block and a function pointer is that the block name is preceded by a caret (^) instead of an asterisk (*). Just like a function pointer, you can pass parameters to a block and receive a return value from it. Listing 3-1 shows you how to declare and execute blocks synchronously in your code. The variable aBlock is declared as aBlock that takes a single integer argument and returns no value. The actual block that matches the stereotype is then allocated to aBlock and declared inline. The last line immediately executes the block, printing the specified integer to standard output.

Listing 3-1 is an example of a simple block

int x = 123;
int y = 456;
 
// Block declaration and assignment
void (^aBlock)(int) = ^(int z) {
    printf("%d %d %d\n", x, y, z);
};
 
/ / Block is carried out
aBlock(789);   // prints: 123 456 789
Copy the code

The following is a summary of some key criteria to consider when designing a module:

• For blocks that you plan to execute asynchronously using a scheduling queue, it is safe to capture scalar variables from a parent function or method and use them in the block. However, you should not attempt to capture large structures or other pointer-based variables that are allocated and deleted by the calling context. By the time your block is executed, the memory referenced by this pointer may have disappeared. Of course, it is safe to allocate memory (or objects) yourself and explicitly transfer ownership of that memory to a block.
• The scheduling queue copies the blocks that are added to it and releases the blocks when the execution is complete. In other words, you do not need to explicitly copy blocks before adding them to the queue.
• Although queues are more efficient than raw threads for performing small tasks, there is still overhead in creating blocks and executing them on the queue. If a block does too little work, it may be cheaper to execute it inline than to dispatch it to a queue. The way to determine if a block is doing too little work is to use a performance tool to collect metrics for each path and compare them.
• Do not cache data associated with the underlying thread with the expectation that it will be accessible from different blocks. If tasks in the same queue need to share data, the context pointer of the schedule queue is used to store the data.
• If your block creates multiple Objective-C objects, you might want to include a portion of the block code in an @AutoRelease block to handle the memory management of those objects. Although GCD scheduling queues have their own automatic release pools, they do not guarantee when these pools will be emptied. If your application is memory constrained, creating your own automatic release pool allows you to free memory for automatic release objects at more regular intervals.

Create and manage scheduling queues

Before adding a task to a queue, you must decide what type of queue you want to use and how you intend to use it. Scheduling queues can execute tasks either sequentially or concurrently. In addition, if you consider the specific purpose of the queue, you can configure the queue properties accordingly. The following sections show you how to create scheduling queues and configure them for use.

Get the global concurrent scheduling queue

Concurrent scheduling queues are useful when you have multiple tasks that can run in parallel. A concurrent queue is still a queue because it takes tasks out in a first-in, first-out order; However, a concurrent queue may cause other tasks to be dequeued before any previous tasks have completed. The actual number of tasks performed by a concurrent queue at any given time is variable and can change dynamically as conditions change in the application. A number of factors affect the number of tasks executed by concurrent queues, including the number of available kernels, the amount of work being completed by other processes, and the number and priority of tasks in other serial-scheduled queues.

The system provides four concurrent scheduling queues for each application. These queues are global to the application and are distinguished only by their priority. Because they are global, you do not have to create them explicitly. Instead, you use the dispatch_GET_global_queue function to request one of the queues, as shown in the following example:

dispatch_queue_t aQueue = dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);
Copy the code

In addition to getting the default concurrent queue, you can also get queues with high and low priority by passing DISPATCH_QUEUE_PRIORITY_HIGH and DISPATCH_QUEUE_PRIORITY_LOW constants to the function. Or get the background queue DISPATCH_QUEUE_PRIORITY_BACKGROUND by passing a constant. As you might expect, tasks in the high-priority concurrent queue execute before tasks in the default queue and the low-priority queue. Again, tasks in the default queue execute before tasks in the low-priority queue.

dispatch_queue_t queue;
queue = dispatch_queue_create("com.example.MyQueue", NULL);
Copy the code

dispatch_queue_t myCustomQueue;
myCustomQueue = dispatch_queue_create("com.example.MyCustomQueue", NULL);
 
dispatch_async(myCustomQueue, ^{
    printf("Do some work here.\n");
});
 
printf("The first block may or may not have run.\n");
 
dispatch_sync(myCustomQueue, ^{
    printf("Do some more work here.\n");
});
printf("Both blocks have completed.\n");
Copy the code

void average_async(int *data, size_t len,
   dispatch_queue_t queue, void (^block)(int))
{
   // Retain the queue provided by the user to make
   // sure it does not disappear before the completion
   // block can be called.
   dispatch_retain(queue);
 
   // Do the work on the default concurrent queue and then
   // call the user-provided block with the results.
   dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{ int avg = average(data, len); dispatch_async(queue, ^{ block(avg); });// Release the user-provided queue when done
      dispatch_release(queue);
   });
}
Copy the code