11 types of locks and performance comparison in iOS development

In daily development, we often use multithreading. Multithreading brings us great convenience and improves the execution efficiency of the program, but it also brings data race. The definition of data race is very simple: when at least two threads access the same variable at the same time, and at least one of them is a write operation, a data race occurs. Therefore, some synchronization mechanisms must be used to ensure the accuracy of the data. Locks are one of the synchronization mechanisms.

How to detect Data race in a project?

Just check Thread Sanitizer in the settings, and by the way, you can check Pause on issues to breakpoint to the corresponding code.

Let's get down to business and talk briefly about locks in iOS and related content (due to my limited ability, there are inevitably some omissions or errors in the article, please feel free to give me your advice! Thank you!)

Simple performance test

The following figure is the result of my own test on the lock in iOS. The numbers in the figure represent the time required for each lock and unlock, in nanoseconds. The code is here, and the code is based on YY's no longer secure OSSpinLock, which is basically the same as YY's figure??, YY's unit is μs, which should be 1000 times, or maybe it's wrong~

Note: The running phone is: iPhone 6s plus, system version: 11.2.2, Xcode 9.2; the unit of the number is ns (the specific value obtained is the average of multiple runs).

It is worth noting that: 1. This number only represents the time taken to unlock each time, and cannot fully represent the performance. 2. Different models and systems, different number of cycles may result in slightly different results.

But it can still be seen that @synchronized: has the worst performance.

Before we talk about these locks in detail, let's first talk about some conceptual definitions: (refer to Wikipedia)

1. Critical section: refers to a piece of code that accesses public resources, not a mechanism or algorithm.
2. Spin lock: A lock used for multi-thread synchronization. The thread repeatedly checks whether the lock variable is available. Since the thread keeps executing during this process, it is a busy wait. Once the spin lock is acquired, the thread will keep the lock until the spin lock is explicitly released. Spin locks avoid the scheduling overhead of the process context, so they are effective for situations where the thread will only be blocked for a short time.
3. Mutex: A mechanism used in multithreaded programming to prevent two threads from reading and writing the same common resource (such as a global variable) at the same time. This purpose is achieved by slicing the code into critical sections one by one.
4. Read-write lock: It is a synchronization mechanism for concurrent control of computer programs, also known as "shared-mutex lock" and multi-reader-single-writer lock) used to solve the problem of multi-threaded reading and writing of common resources. Read operations can be reentered concurrently, and write operations are mutually exclusive. Read-write locks are usually implemented with mutex locks, condition variables, and semaphores.
5. Semaphore: It is a more advanced synchronization mechanism. Mutex can be said to be a special case of semaphore when it only takes the value 0/1. Semaphore can have more value spaces and is used to achieve more complex synchronization, not just mutual exclusion between threads.
6. Condition lock: It is a condition variable. When some resource requirements of the process are not met, it goes into sleep, that is, locked. When the resources are allocated, the condition lock is opened and the process continues to run.

Mutex

1.NSLock: It is a lock exposed to developers in the form of an object in the Foundation framework (the Foundation framework also provides NSConditionLock, NSRecursiveLock, and NSCondition).NSLock is defined as follows:

 @protocol NSLocking
 - (void)lock;
 - (void)unlock;
 @ end  
 @interface NSLock : NSObject <nslocking> {
 @private
 void *_priv;
 }
 - (BOOL)tryLock;
 - (BOOL)lockBeforeDate:(NSDate *)limit;
 @property (nullable, copy) NSString * name API_AVAILABLE(macos(10.5), ios(2.0), watchos(2.0), tvos(9.0));
 @ end </nslocking>

Both tryLock and lock methods request locks. The only difference is that trylock can continue to do some tasks and processing when the lock is not obtained. The lockBeforeDate method is also relatively simple, which is to obtain the lock before the limit time point, and return NO if it is not obtained.

In the actual project: NSLock is used in AFURLSessionManager.m of AFNetworking as follows:

 - (instancetype)initWithSessionConfiguration:(NSURLSessionConfiguration *)configuration {
 ...
    self.lock = [[NSLock alloc] init];
    self.lock.name = AFURLSessionManagerLockName;
 ...
 }
 - (void)setDelegate:(AFURLSessionManagerTaskDelegate *)delegate
            forTask:(NSURLSessionTask *)task
 {
 ...
 [self.lock lock];
    self.mutableTaskDelegatesKeyedByTaskIdentifier[@(task.taskIdentifier)] = delegate;
    [delegate setupProgressForTask:task];
    [self addNotificationObserverForTask:task];
 [self.lock unlock];
 }

2.pthread_mutex:

In actual projects: You can see this in YYMemoryCach of YYKit

 - (instancetype)init {
 ...
    pthread_mutex_init(&_lock, NULL );
 ...
 }
 - (void)_trimToCost:(NSUInteger)costLimit {
 BOOL finish = NO ;
    pthread_mutex_lock(&_lock);
 if (costLimit == 0) {
 [_lru removeAll];
 finish = YES;
    } else if (_lru->_totalCost <= costLimit) {
 finish = YES;
 }
    pthread_mutex_unlock(&_lock);
 if (finish) return ; 
      
    NSMutableArray *holder = [NSMutableArray new];
 while (!finish) {
        if (pthread_mutex_trylock(&_lock) == 0) {
            if (_lru->_totalCost > costLimit) {
                _YYLinkedMapNode *node = [_lru removeTailNode];
                if (node) [holder addObject:node];
 } else {
 finish = YES;
 }
            pthread_mutex_unlock(&_lock);
 } else {
            usleep(10 * 1000); //10 ms
 }
 }
 ...
 }

3.@synchronized:

In the actual project: getter method of isNetworkActivityOccurring attribute in AFNetworking

 - (BOOL)isNetworkActivityOccurring {
 @synchronized(self) {
 return self.activityCount > 0;
 }
 }

Spin lock

1.OSSpinLock:

 OSSpinLock lock = OS_SPINLOCK_INIT;
 OSSpinLockLock(&lock);
 ...
 OSSpinLockUnlock(&lock);

The above is how to use OSSpinLock. The compiler will report a warning that it has been deprecated. OSSpinLock is no longer used because it is no longer safe in some scenarios. You can refer to YY master's no longer safe OSSpinLock. In the Protocol Buffers project, you can see such comments. Everyone has replaced it with a new solution.

 // NOTE: OSSpinLock may seem like a good fit here but Apple engineers have
  // pointed out that they are vulnerable to live locking on iOS in cases of  
 // priority inversion:
  // http://mjtsai.com/blog/2015/12/16/osspinlock- is -unsafe/
  // https://lists.swift.org/pipermail/swift-dev/Week- of -Mon-20151214/000372.html

2.os_unfair_lock:

os_unfair_lock is the solution officially recommended by Apple to replace OSSpinLock, but it can only be called in systems above iOS10.0.

 os_unfair_lock_t unfairLock;
 unfairLock = &(OS_UNFAIR_LOCK_INIT);
 os_unfair_lock_lock(unfairLock);
 os_unfair_lock_unlock(unfairLock);

Read-write lock

As mentioned above, the read-write lock is also called a shared-mutex lock.

pthread_rwlock:

 //Add read lock
 pthread_rwlock_rdlock(&rwlock);
 //Unlock
 pthread_rwlock_unlock(&rwlock);
 //Add write lock
 pthread_rwlock_wrlock(&rwlock);
 //Unlock
 pthread_rwlock_unlock(&rwlock);

Recursive Lock

A feature of recursive locks is that the same thread can be locked N times without causing deadlock.

1.NSRecursiveLock:

NSRecursiveLock is used in YYWebImageOperation.m in YYKit:

 _lock = [NSRecursiveLock new];
 - (void)dealloc {
 [_lock lock];
 ...
 ...
 [_lock unlock];
 }

2.pthread_mutex(recursive):

The pthread_mutex lock also supports recursion, just set PTHREAD_MUTEX_RECURSIVE

 pthread_mutex_t lock;
 pthread_mutexattr_t attr;
 pthread_mutexattr_init(&attr);
 pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_RECURSIVE);
 pthread_mutex_init(&lock, &attr);
 pthread_mutexattr_destroy(&attr);
 pthread_mutex_lock(&lock);
 pthread_mutex_unlock(&lock);

Conditional Lock

1. NSCondition:

definition:

 @interface NSCondition : NSObject <nslocking> {
 @private
 void *_priv;
 }
 - (void)wait;
 - (BOOL)waitUntilDate:(NSDate *)limit;
 - (void)signal;
 - (void)broadcast;</nslocking>

Follow the NSLocking protocol. When used, it is also lock, unlock and unlock. Wait is to wait stupidly. The waitUntilDate: method is to wait for a while, which will block the thread. Signal is to wake up a waiting thread, and broadcast is to broadcast and wake up all.

 NSCondition *lock = [[NSCondition alloc] init];
 //Son thread
 dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
 [lock lock];
 while ( No Money ) {
 [lock wait];
 }
    NSLog(@ "The money has been used up." );
 [lock unlock];
 }); 
      
 //Father thread
 dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
 [lock lock];
    NSLog(@ "Work hard to make money." );
 [lock signal];
 [lock unlock];
 });

2.NSConditionLock:

definition:

 @interface NSConditionLock : NSObject <nslocking> {
 @private
 void *_priv;
 }
 - (instancetype)initWithCondition:(NSInteger)condition NS_DESIGNATED_INITIALIZER;
 @property (readonly) NSInteger condition;
 - (void)lockWhenCondition:(NSInteger)condition;
 - (BOOL)tryLock;
 - (BOOL)tryLockWhenCondition:(NSInteger)condition;
 - (void)unlockWithCondition:(NSInteger)condition;
 - (BOOL)lockBeforeDate:(NSDate *)limit;
 - (BOOL)lockWhenCondition:(NSInteger)condition beforeDate:(NSDate *)limit;</nslocking>

It’s very simple, the method is very clear, and it’s basically the same as above.

Semaphore

dispatch_semaphore:

dispatch_semaphore is used in YYThreadSafeArray.m in YYKit, and YY master has such a comment:

 @discussion Generally, access performance is   lower than NSMutableArray,  
 but higher than using @synchronized, NSLock, or pthread_mutex_t.
 3#define LOCK(...) dispatch_semaphore_wait(_lock, DISPATCH_TIME_FOREVER); \  
 __VA_ARGS__; \  
 dispatch_semaphore_signal(_lock);

Summarize:

In fact, this article is all about the most basic content. When reading some open source projects, you will often encounter some ways to keep threads synchronized. Because the selection may be different in different scenarios, this article will just make a simple record~ I believe that after reading this article, you should be able to choose the right lock according to different scenarios, and be able to tell the difference between spin locks and mutex locks.

at last:

Due to my limited ability, there are inevitably some omissions or errors in the article. Please feel free to give me your advice! Thank you! At the same time, if you have any questions about locks, you can leave a message, communicate together, and make progress together~?? I hope everyone can make a little progress every day~