Essential concurrency Programming Tips for iOS developers

in the There are often problems in iOS concurrent programming, we are not here to explore the specific usage of nsthread, GCD, Nsoperation, Nsoperationqueue, but to explore some easily forgotten dots. I hope that the vast number of iOS developers can play a certain help.

Thread cost

on Wikipedia The explanation of the thread is :

A thread of execution is the smallest sequence of programmed instructions so can be managed independently by a scheduler .

in layman's terms, thread, which is a separate code execution path, which means that the thread is the smallest branch of the Code execution path. In IOS, the underlying implementation of threads is based on the POSIX threads API, which is what we often call pthreads.

In iOS, after a process is started, one of the most important threads we call the main thread. The main thread creates and manages all of the UI elements. In general, disruptive operations related to user interaction are distributed to the main thread for processing, including your ibaction method.

The creation of threads is cost-intensive, and each thread takes time not only in the process of creation, but also in the memory space of the kernel and in the memory of the app.

about iOS multithreaded development more detailed content recommended to watch: iOS multi-threaded and Asynchronous task Processing (http://www.maiziedu.com/course/ios/23-2525/)

Kernel data structure (Kernel data structures)

according Official Documents , each thread consumes approximately 1KB of memory on the kernel space. This memory is used to store the data structure and properties of the thread. This is a wired memory, and cannot be paged on disk.

This memory was used to store the thread data structures and attributes, much of which is allocated as wired memory and the Refore cannot is paged to disk.

Line Stacks space size (Stack space)

In iOS, the main thread has a stack size of 1MB, and in OS X the main thread has a stack space of 8MB, and this is not modifiable. The child thread default stack space is 512KB.

The stack space is not immediately created and allocated, and it grows as you use it. So, even if the main thread has 1MB of stack space, you will only use a very small part of it for a large period of time.

The minimum stack space that a child thread allows to allocate is 16KB, and must be a multiple of 4KB. We can modify the stack space of a child thread through the StackSize property:

Nsthread *t = [[Nsthread alloc] Initwithtarget:target

Selector:selector Object:object];

t.stacksize = size;

Thread creation time (Creation)

The figures were determined by analyzing the mean and median values generated during thread creation on an intel-based iMa C with a 2 GHz Core Duo processor and 1 GB of RAM running OS X v10.5.

according Official Documents , in a 2GHz dual-core Intel processor, 1GB memory, OS X 10.5 system imac, it takes 90 microseconds (some people write 90ms or 90 milliseconds, in fact, the MS here is microsecond, not millisecond )。

Atomic Properties

When declaring a property, we have two choices, one is atomic, one is Nonatomic, the former is atomic, the latter is non-atomic. Basically, the difference is that atomic will add a mutex to the setter method of the property (there is also a claim to use the spin lock spin locks, however, because of a spin lock bug, Apple may not use a spin lock, instead using Pthread_mutex or di Spatch_semaphore, etc.):

Atomic

-(void) Setcurrentimage: (UIImage *) currentimage

{

@synchronized (self) {

if (_currentimage! = currentimage) {

_currentimage = Currentimage;

}

}

}

-(UIImage *) currentimage

{

@synchronized (self) {

return _currentimage;

}

}

Nonatomic

-(void) Setcurrentimage: (UIImage *) currentimage

{

if (_currentimage! = currentimage) {

_currentimage = Currentimage;

}

}

-(UIImage *) currentimage

{

return _currentimage;

}

Properties are atomic decorated by default, and explicitly written nonatomic are non-atomic operations.

Like what:

@property (nonatomic, strong) Uitextfield *username;

@property (Atomic, strong) Uitextfield *username;

@property (strong) Uitextfield *username;

The latter two are actually the same, only the first is the non-atomic operation.

Is it thread safe?

From the above code, atomic can only guarantee that the setter and getter methods of the property are thread-safe.

Let's take an example, if it happens at the same time:

Thread A calls the Getter method.

Thread B, thread C call setter methods, and they set the values to be inconsistent.

Then, thread A might get the original value, or it might get the value of thread B or thread C, which is not necessarily the case. Also, the final value of the property might be thread B, or the value set by thread C.

In the words "effective OBJECTIVE-C 2.0" above, it is:

This can provide some degree of "thread safety", but there is no guarantee that access to the object is absolutely thread-safe. Of course, the operation of accessing properties is really "atomic". When you use attributes, you must be able to get valid values from them, but the fetch method is called multiple times on the same thread, and the result is not necessarily the same. Between two access operations, other threads may write new values.

So, to talk about the real thread safety, the atomic gap is still a bit big.

Should you use it?

In the absence of competition for resources (for example, single-threaded), atomic may be very fast, but in a more general case, atomic is likely to have a 20 times-fold performance difference compared to nonatomic, which has been tested in the stack overflow.

So, whether or not to use atomic, this depends on whether you need. For me, I generally rarely use atomic, if necessary, I will generally use dispatch_barrier instead (for example, refer to the following Dispatch_barrier setter and getter notation).

about Concurrency synchronization issues, the next installment will give practical examples.

Essential concurrency Programming Tips for iOS developers