Those things within IOS multithreading (on)

As we all know, Apple's Mac OS X system and IOS system are based on three parts. Bsd unix, Mach, and iokit developed by Apple constitute the main body of the operating system, that is, the Darwin framework. Among them, Mach is mainly responsible for CPU management, memory protection, and inter-process communication. From the bsd unix side, it is basically the network performance, operation efficiency, and standardized posix api. In most cases, for Unix users or developers, POSIX APIs basically provide everything they need for multi-threaded programming. Multithreading Based on POSIX APIProgramIt is often the most standard and the easiest to transplant. EspeciallyCodeFor IOS developers, translating other multi-threaded code to POSIX is the most convenient. This is mainly because posix api has already formed a standard. As long as there is a multi-threaded program, there must be a POSIX shadow.

Of course, it is indeed the most convenient for cross-platform developers. However, for iOS native developers, just using the posix api seems a little thin. In particular, when developers bring this fixed set of multi-threaded programming ideas to iOS development, they will encounter some small problems. In this articleArticle(And several articles in the future) I will discuss this issue with you and provide some opinions on this issue.

In fact, in practice, in most cases, multithreading is not particularly necessary. This is the first conclusion. In general, at our level, multithreading is mainly used to solve problems such as user interface interaction, such as time-consuming operations such as networks, most of the time, we will move this operation to another thread to avoid the main interface getting stuck. In fact, all of the above are parallel processing. in a strict sense, parallel processing is not necessarily a multi-thread. The simplest example is an open-source library that everyone is using: cocoasocket provides two parallel sockets based on GCD and runloop, while the latter is not thread-safe. Of course, this may not be accurate enough. For accuracy, it is like most foundation classes that can be used on any thread, however, if access is performed on another thread, an error will occur (basically nsmutable classes ). In fact, the runloop-based socket can also provide a good solution for Parallel Processing (cfsocket itself is also based on runloop ). Nsunloop and cfrunloop are thread-based, but they are not unique to multithreading (note that even a single thread is a thread) and have a unique behavior pattern. I will talk about this in the next article.

Of course, for iOS multi-threaded programs, the most difficult part is runloop. In simple cases, a working thread can loop itself infinitely, so that it can be always in the working state, and all the problems such as time scheduling can be thrown to the operating system. In the IOS environment, this is not perfect for the use of system resources. In fact, runloop is equivalent to a database Integrated by Apple for thread sleep and wake-up. Each thread can have a runloop. In this mode, the thread consumes the least CPU time, because the operating system can choose when to send this runloop to sleep state based on your code: This will be discussed later.

In use, many items in the foundation class are related to runloop. The most common class is nstimer. In many systems, events triggered Based on Time Intervals generally work in a single process (most of which are system-managed processes, therefore, most of the time we mistakenly believe that nstimer will achieve parallel effects with the main thread. In fact, since nstmer is based on runloop, Timer is a type of runloop source. Therefore, nstimer on the same thread cannot achieve the parallel effect. This means that the second timer will not be triggered before the code of the First timer is executed. This can be easily verified by a timer whose content is an endless loop. This is also equivalent to adding multi‑thread synchronization or protection measures to nstimer code, which is not necessary. This situation may only occur when two timers are added to different threads respectively.

For nstimer, there are many other interesting features. For example, re-planning an nstimer is a very time-consuming task. The reason is also related to nstimer being based on runloop rather than system threads. In the next article, we will discuss in detail the runloop and its precautions.