iOS multithreaded development: several details that are easily overlooked

Generally speaking, iOS developers can handle most multi-threaded development as long as they can use a few simple APIs such as GCD, @synchronized, NSLock, etc. However, does this really achieve multi-threaded safety, and does it really fully utilize the efficiency advantages of multi-threading? Take a look at the following details that are easily overlooked.

Readers-writers problem

First, let's look at the description of the reader-writer problem:

There are two sets of concurrent threads, readers and writers, sharing the same data. When two or more reader threads access the shared data at the same time, no side effects will occur. However, if a writer thread and other threads (reader threads or writer threads) access the shared data at the same time, data inconsistency errors may occur. Therefore, the following requirements are required:

• Allow multiple readers to perform read operations on shared data simultaneously;
• Only one writer is allowed to write to shared data;
• Any writer does not allow other readers or writers to work until the write operation is completed;
• Before a writer performs a write operation, it should make all existing readers and writers exit.

From the above description, we can know that the so-called "reader-writer problem" refers to the synchronization problem of ensuring that a writing thread must access a shared object exclusively with other threads. Concurrent read operations are allowed, but write operations must be mutually exclusive with other read and write operations.

Most client apps simply pull the latest data from the network, process the data, and display the data in a list. This process involves both writing the latest data to the local server and reading the local data from the upper-level business. Therefore, it involves a large number of multi-threaded read and write operations. Obviously, these basically fall into the category of reader-writer problems [1].

However, I noticed that when faced with multi-threaded reading and writing problems, most iOS developers would immediately think of locking, or simply avoid using multi-threading, but few would try to use the reader-writer problem to further improve efficiency.

The following is a sample code to implement a simple cache:

 //Implement a simple cache
 - (void)setCache:(id)cacheObject forKey:(NSString *) key {
 if ( key .length == 0) {
 return ;
 }
 [_cacheLock lock];
    self.cacheDic[ key ] = cacheObject;
 ...
 [_cacheLock unlock];
 } 
 
 - (id)cacheForKey:(NSString * key ) {
 if ( key .length == 0) {
 return nil;
 }
 [_cacheLock lock];
    id cacheObject = self.cacheDic[ key ];
 ...
 [_cacheLock unlock];
 return cacheObject;
 }

The above code uses a mutex lock to implement multi-threaded reading and writing, which ensures safe reading and writing of data. However, the efficiency is not perfect because in this case, although the write operation and other operations are mutually exclusive, the read operations are also mutually exclusive, which will waste CPU resources. How to improve it? It is not difficult to find that this is actually a typical reader-writer problem. Let's take a look at the pseudo code to solve the reader-writer problem:

 semaphore ReaderWriterMutex = 1; //Realize read-write mutual exclusion
 int Rcount = 0; //Number of readers
 semaphore CountMutex = 1; //Reader modifies count mutex 
 
 writer(){
 while( true ){
 P(ReaderWriterMutex);
 write;
 V(ReaderWriterMutex);
 } 
     
 } 
 
 reader(){
 while( true ){
 P(CountMutex);
 if(Rcount == 0) //When the first reader comes in, block the writer
            P(ReaderWriterMutex);
 ++Rcount;
 V(CountMutex); 
 
 read ; 
 
 P(CountMutex);
 --Rcount;  
 if(Rcount == 0)
 V(ReaderWriterMutex); //When the last reader leaves, release the writer
 V(CountMutex);
 }
 }

In iOS, the PV primitive in the above code can be replaced with the semaphore API in GCD, dispatch_semaphore_t to implement it, but it is necessary to maintain an additional readerCount and implement the semaphore for readerCount mutual exclusive access. Manual implementation is more troublesome and it is difficult to encapsulate it into a unified interface. Fortunately, you can find ready-made reader-writer locks in iOS development:

pthread_rwlock_t

This is an old C language function, which is used as follows:

 // Initialization of lock, pthread_rwlock_t is a value type and must be declared as var in   order   to refer it later. Make sure not   to copy it.
 var lock = pthread_rwlock_t()
 pthread_rwlock_init(&lock, nil) 
 
 // Protecting read   section :
 pthread_rwlock_rdlock(&lock)
 // Read shared resource
 pthread_rwlock_unlock(&lock) 
 
 // Protecting write section :
 pthread_rwlock_wrlock(&lock)
 // Write shared resource
 pthread_rwlock_unlock(&lock) 
 
 // Clean up
 pthread_rwlock_destroy(&lock)

The interface is concise but not user-friendly. It should be noted that pthread_rwlock_t is a value type. Using = to assign a value will directly copy it, which will waste memory if you are not careful. In addition, you need to remember to destroy it after use, which is prone to errors. Is there a more advanced and easier-to-use API?

GCD barrier

Dispatch_barrier_async / dispatch_barrier_sync is not specifically used to solve the reader-writer problem. Barrier is mainly used in the following scenarios: when executing a task A, all operations previously added to the queue need to be completed, and tasks added later need to wait for task A to be completed before they can be executed, thereby isolating task A. The specific process is shown in the following figure:

If the concurrent tasks before and after the barrier task are replaced by read operations, and the barrier task itself is replaced by a write operation, dispatch_barrier_async / dispatch_barrier_sync can be used as a reader-writer lock. The cache code implemented using a normal lock at the beginning of the article is rewritten using dispatch_barrier_async for comparison:

 //Implement a simple cache (using ordinary locks)
 - (void)setCache:(id)cacheObject forKey:(NSString *) key {
 if ( key .length == 0) {
 return ;
 }
 [_cacheLock lock];
    self.cacheDic[ key ] = cacheObject;
 ...
 [_cacheLock unlock];
 } 
 
 - (id)cacheForKey:(NSString * key ) {
 if ( key .length == 0) {
 return nil;
 }
 [_cacheLock lock];
    id cacheObject = self.cacheDic[ key ];
 ...
 [_cacheLock unlock];
 return cacheObject;
 }

 //Implement a simple cache (using reader-writer locks)
 static dispatch_queue_t queue = dispatch_queue_create( "com.gfzq.testQueue" , ​​DISPATCH_QUEUE_CONCURRENT); 
 
 - (void)setCache:(id)cacheObject forKey:(NSString *) key {
 if ( key .length == 0) {
 return ;
 }
    dispatch_barrier_async(queue, ^{
        self.cacheDic[ key ] = cacheObject;
 ...
 });
 } 
 
 - (id)cacheForKey:(NSString * key ) {
 if ( key .length == 0) {
 return nil;
 }
    __block id cacheObject = nil;
 dispatch_sync(queue, ^{
        cacheObject = self.cacheDic[ key ];
 ...
 });
 return cacheObject;
 }

The cache implemented in this way can perform read operations concurrently while effectively isolating write operations, taking into account both security and efficiency.

For properties that are declared as atomic and have their getters or setters manually implemented, barriers can also be used to improve them:

 @property (atomic, copy) NSString *someString; 
 
 - (NSString *)someString {
    __block NSString *tempString;
    dispatch_sync(_syncQueue, ^{
        tempString = _someString;
 });
 return tempString;
 } 
 
 - (void)setSomeString :(NSString *)someString {
    dispatch_barrier_async(_syncQueue, ^{
        _someString = someString
 ...
 }
 }

While achieving atomicity, getters can also be executed concurrently, which is more efficient than directly putting setters and getters into serial queues or adding ordinary locks.

How much efficiency can readers and writers locks improve?

Using reader-writer locks is definitely faster than locking all reads and writes and using serial queues, but how much faster can it be? Dmytro Anokhin conducted an experimental comparison in [3] and measured the average time required to acquire locks when using NSLock, GCD barrier, and pthread_rwlock. The number of experimental samples ranged from 100 to 1000, excluding 10% of *** and ***. The results are shown in the following chart:

3 writers / 10 readers

1 writer / 10 readers

5 writers / 5 readers

10 writers / 1 reader

Analysis shows that:

1. Using reader-writer locks (GCD barrier, pthread_rwlock) significantly improves efficiency compared to using ordinary locks (NSLock);
2. The more readers there are and the fewer writers there are, the more efficiency advantage of using reader-writer locks becomes;
3. There is little difference in efficiency between using GCD barrier and using pthread_rwlock.

Since pthread_rwlock is not easy to use and prone to errors, and the performance of GCD barrier and pthread_rwlock is comparable, it is recommended to use GCD barrier to solve the reader-writer problem encountered in iOS development. In addition, there is a potential advantage of using GCD: GCD is queue-oriented rather than thread-oriented. Tasks dispatched to a queue may be executed on any thread. This is transparent to developers. The benefits of such a design are obvious. GCD can select the thread with the lowest overhead from the thread pool it manages to execute tasks according to actual conditions, thereby minimizing the number of context switches.

When to use readers-writer locks

It should be noted that not all multi-threaded read and write scenarios are necessarily reader-writer problems, so be careful to distinguish when using them. For example, the following YYCache code:

 //Read cache
 - (id)objectForKey:(id) key {
 if (! key ) return nil;
    pthread_mutex_lock(&_lock);
    _YYLinkedMapNode *node = CFDictionaryGetValue(_lru->_dic, (__bridge const void *)( key ));
 if (node) {
        node->_time = CACurrentMediaTime();
        [_lru bringNodeToHead:node];
 }
    pthread_mutex_unlock(&_lock);
 return node ? node->_value : nil;
 }

 //Write cache
 - (void)setObject:(id)object forKey:(id) key withCost:(NSUInteger)cost {
 if (! key ) return ;
 if (!object) {
        [self removeObjectForKey: key ];
 return ;
 }
    pthread_mutex_lock(&_lock);
    _YYLinkedMapNode *node = CFDictionaryGetValue(_lru->_dic, (__bridge const void *)( key ));
    NSTimeInterval now = CACurrentMediaTime();
 if (node) {
        _lru->_totalCost -= node->_cost;
        _lru->_totalCost += cost;
 node->_cost = cost;
 node->_time = now;
        node->_value = object;
        [_lru bringNodeToHead:node];
 } else {
        node = [_YYLinkedMapNode new];
 node->_cost = cost;
 node->_time = now;
 node->_key = key ;
        node->_value = object;
        [_lru insertNodeAtHead:node];
 }
    if (_lru->_totalCost > _costLimit) {
        dispatch_async(_queue, ^{
            [self trimToCost:_costLimit];
 });
 }
    if (_lru->_totalCount > _countLimit) {
        _YYLinkedMapNode *node = [_lru removeTailNode];
        if (_lru->_releaseAsynchronously) {
            dispatch_queue_t queue = _lru->_releaseOnMainThread ? dispatch_get_main_queue() : YYMemoryCacheGetReleaseQueue();
            dispatch_async(queue, ^{
                [node class]; //hold and release in queue
 });
        } else if (_lru->_releaseOnMainThread && !pthread_main_np()) {
            dispatch_async(dispatch_get_main_queue(), ^{
                [node class]; //hold and release in queue
 });
 }
 }
    pthread_mutex_unlock(&_lock);
 }

The cache here uses the LRU elimination strategy. Each time the cache is read, the cache is placed at the front of the data structure, thereby delaying the elimination of the most recently used cache. Because a write operation also occurs at the same time as a read operation, the pthread_mutex mutex is used directly here instead of the reader-writer lock.

To sum up, if the multi-threaded reading and writing scenarios you encounter meet the following requirements:

1. There is a pure read operation (that is, the read task does not include a write operation at the same time);
2. There are more readers and fewer writers.

You should consider using reader-writer locks to further improve concurrency.

Notice:

(1) The reader-writer problem includes two categories: "reader priority" and "writer priority". The former means that as long as the reader thread sees that other reader threads are accessing the file, it can continue to read the file, and the writer thread must wait until all reader threads stop accessing the file before writing, even if the writer thread may submit an application earlier than some reader threads. The writer priority means that as long as the writer thread submits an application, the subsequent reader thread must wait for the writer thread to complete. GCD's barrier is a writer priority implementation. For details, please refer to document [2].

(2) There is no need to use GCD barriers on serial queues. Instead, use the concurrent queue created with dispatch_queue_create. Since dispatch_get_global_queue is a global shared queue, using barriers cannot isolate the current task and will automatically downgrade to dispatch_sync / dispatch_async. [5]

Granularity of Locks

First, let’s look at two pieces of code:

Code Snippet 1

 @property (atomic, copy) NSString *atomicStr; 
 
 //thread A
 atomicSr = @ "am on thread A" ;
 NSLog(@ "%@" , atomicStr); 
 
 //thread B
 atomicSr = @ "am on thread B" ;
 NSLog(@ "%@" , atomicStr);

Code Snippet 2

 - (void)synchronizedAMethod {
 @synchronized (self) {
 ...
 }
 } 
 
 - (void)synchronizedBMethod {
 @synchronized (self) {
 ...
 }
 } 
 
 - (void)synchronizedCMethod {
 @synchronized (self) {
 ...
 }
 }

Too small particle size

When executing code segment 1, the string printed on thread A may be "am on thread B". The reason is that although atomicStr is an atomic operation, after atomicStr is taken out and before NSLog is executed, atomicStr may still be modified by thread B. Therefore, the properties declared with atomic can only guarantee that the get and set of the property are complete, but cannot guarantee that the operations on the property after get and set are multi-thread safe. This is why the properties declared with atomic cannot necessarily guarantee multi-thread safety.

Similarly, it is not just the properties declared by atomic. If the granularity of the locks added by yourself during development is too small, thread safety cannot be guaranteed. Code segment 1 actually has the same effect as the following code:

 @property (nonatomic, strong) NSLock *lock;
 @property (nonatomic, copy) NSString *atomicStr; 
 
 //thread A
 [_lock lock];
 atomicSr = @ "am on thread A" ;
 [_lock unlock];
 NSLog(@ "%@" , atomicStr); 
 
 //thread B
 [_lock lock];
 atomicSr = @ "am on thread B" ;
 [_lock unlock];
 NSLog(@ "%@" , atomicStr);

If we want the program to print the set value after setting atomicStr as we originally intended, we need to increase the scope of the lock and include NSLog in the critical section:

 //thread A
 [_lock lock];
 atomicSr = @ "am on thread A" ;
 NSLog(@ "%@" , atomicStr);
 [_lock unlock]; 
 
 //thread B
 [_lock lock];
 atomicSr = @ "am on thread B" ;
 NSLog(@ "%@" , atomicStr);
 [_lock unlock];

The sample code is very simple and it is easy to see the problem, but when you encounter more complex code blocks in actual development, you may fall into a trap if you are not careful. Therefore, when designing multi-threaded code, you should pay special attention to the logical relationship between the codes. If the subsequent code depends on the locked code, then these subsequent codes should also be added to the lock.

Too large granularity

The @synchronized keyword will automatically create a lock associated with the passed object, automatically lock it at the beginning of the code block, and automatically unlock it at the end of the code block. The syntax is simple and clear, and it is very easy to use, but this also causes some developers to rely too much on the @synchronized keyword and abuse @synchronized(self). As shown in the above code segment 2, in an entire class file, all locked places use @synchronized(self), which may cause unrelated threads to wait for each other when executing, and tasks that could have been executed concurrently have to be executed serially. In addition, using @synchronized(self) may also cause deadlock:

 //class A 
 
 @synchronized (self) {
 [_sharedLock lock];
    NSLog(@ "code in class A" );
 [_sharedLock unlock];
 } 
 
 //class B
 [_sharedLock lock];
 @synchronized (objectA) {
    NSLog(@ "code in class B" );
 }
 [_sharedLock unlock];

The reason is that self is likely to be accessed by external objects and used as a key to generate a lock, similar to @synchronized (objectA) in the above code. Deadlock is likely to occur when two public locks are used alternately. Therefore, the correct approach is to pass in an NSObject object maintained internally by the class, and this object is not visible to the outside world [2].

Therefore, different locks should be set for unrelated multi-threaded codes, and each lock only controls one critical section. In addition, there is another common mistake that will lead to a decrease in concurrency efficiency:

 //thread A
 [_lock lock];
 atomicSr = @ "am on thread A" ;
 NSLog(@ "%@" , atomicStr);
 //do some other tasks which are none of business with atomicStr;
 for ( int i = 0; i < 100000; i ++) {
 sleep(5);
 }
 [_lock unlock]; 
 
 //thread B
 [_lock lock];
 atomicSr = @ "am on thread B" ;
 NSLog(@ "%@" , atomicStr);
 //do some other tasks which are none of business with atomicStr;
 for ( int i = 0; i < 100000; i ++) {
 sleep(5);
 }
 [_lock unlock];

That is, the critical section contains tasks that are unrelated to the current locked object. In practical applications, we need to pay special attention to each function in the critical section, because its internal implementation may call time-consuming and irrelevant tasks.

Recursive lock

Compared with the above-mentioned @synchronized(self), the deadlock caused by the following situation is more common:

 @property (nonatomic,strong) NSLock *lock; 
 
 _lock = [[NSLock alloc] init]; 
 
 - (void)synchronizedAMethod {
 [_lock lock];
 //do some tasks
    [self synchronizedBMethod];
 [_lock unlock];
 } 
 
 - (void)synchronizedBMethod {
 [_lock lock];
 //do some tasks
 [_lock unlock];
 }

After method A has acquired the lock, calling method B will trigger a deadlock. Method B can only continue to execute after waiting for method A to complete and release the lock. The prerequisite for method A to complete is to complete method B. In actual development, the situation where deadlock may occur is often hidden in the layers of method calls. Therefore, it is recommended to use recursive locks when it is uncertain whether a deadlock will occur. A more conservative approach is to use recursive locks at all times, because it is difficult to guarantee that future code will not lock the same thread multiple times.

Recursive locks allow the same thread to repeatedly lock the lock it owns without releasing it, and this is done internally using a counter. In addition to NSRecursiveLock, you can also use pthread_mutex_lock, which has better performance, by setting the initialization parameter to PTHREAD_MUTEX_RECURSIVE:

 pthread_mutexattr_t attr;
 pthread_mutexattr_init (&attr);
 pthread_mutexattr_settype (&attr, PTHREAD_MUTEX_RECURSIVE);
 pthread_mutex_init (&_lock, &attr);
 pthread_mutexattr_destroy (&attr);

It is worth noting that @synchronized also uses recursive locks internally:

 // Begin synchronizing on   'obj' .
 // Allocates recursive mutex associated with   'obj' if needed.
 // Returns OBJC_SYNC_SUCCESS once lock is acquired.
 int objc_sync_enter(id obj)
 {
 int result = OBJC_SYNC_SUCCESS; 
 
 if (obj) {
        SyncData* data = id2data(obj, ACQUIRE);
 assert(data);
 data->mutex.lock();
 } else {
        // @synchronized(nil) does nothing
 if (DebugNilSync) {
            _objc_inform( "NIL SYNC DEBUG: @synchronized(nil); set a breakpoint on objc_sync_nil to debug" );
 }
 objc_sync_nil();
 } 
 
 return result;
 }

Summarize

If you want to write efficient and safe multi-threaded code, it is not enough to be familiar with the GCD, @synchronized, and NSLock APIs. You also need to understand more about the knowledge behind the APIs. It is necessary to have a deep understanding of the concept of critical sections and clarify the timing relationship between tasks.