iSO development skills—Notification and multithreading

A few days ago, I discussed with my colleagues the issue of forwarding Notification under multi-threading, so I would like to sort it out.

Let's take a look at the official documentation first, which is written like this:

In a multithreaded application, notifications are always delivered in the thread in which the notification was posted, which may not be the same thread in which an observer registered itself.

Translated:

In a multi-threaded application, Notification is forwarded in the thread in which it is posted, not necessarily in the thread in which the observer is registered.

That is to say, the sending and receiving of Notification are all done in the same thread. To illustrate this, let's take a look at an example:

Code Listing 1: Sending and processing Notification

 @implementation ViewController 
 
 - ( void )viewDidLoad {
 [ super viewDidLoad]; 
 
 NSLog(@ "current thread = %@" , [NSThread currentThread]); 
 
 [[NSNotificationCenter defaultCenter] addObserver:self selector: @selector (handleNotification:) name:TEST_NOTIFICATION object:nil]; 
 
 dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0 ), ^{ 
 
 [[NSNotificationCenter defaultCenter] postNotificationName:TEST_NOTIFICATION object:nil userInfo:nil];
 });
 } 
 
 - ( void )handleNotification:(NSNotification *)notification
 {
 NSLog(@ "current thread = %@" , [NSThread currentThread]); 
 
 NSLog(@ "test notification" );
 } 
 
 @end  

The output is as follows:

 2015-03-11​​​​   22 : 05 : 12.856 test[ 865 : 45102 ] current thread = <NSThread: 0x7fbb23412f30 >{number = 1 , name = main}
 2015-03-11​​​​   22 : 05 : 12.857 test[ 865 : 45174 ] current thread = <NSThread: 0x7fbb23552370 >{number = 2 , name = ( null )}
 2015-03-11​​​​   22 : 05 : 12.857 test[ 865 : 45174 ]test notification

As you can see, although we registered the notification observer in the main thread, the Notification posted in the global queue is not processed in the main thread. Therefore, we need to pay attention at this time. If we want to process UI-related operations in the callback, we need to ensure that the callback is executed in the main thread.

At this point, there is a problem. If our Notification is posted in the secondary thread, how can we process this Notification in the main thread? Or to put it another way, if we want the post thread of a Notification to be different from the forwarding thread, what should we do? Let's see what the official document says:

For example, if an object running in a background thread is listening for notifications from the user interface, such as a window closing, you would like to receive the notifications in the background thread instead of the main thread. In these cases, you must capture the notifications as they are delivered on the default thread and redirect them to the appropriate thread.

Here we talk about "redirection", which means that we capture these distributed notifications in the default thread where Notification is located, and then redirect them to the specified thread.

One way to implement redirection is to customize a notification queue (note, not an NSNotificationQueue object, but an array) and let this queue maintain the Notifications we need to redirect. We still register a notification observer as usual. When a Notification comes, we first check whether the thread that posts this Notification is the thread we expect. If not, we store this Notification in our queue and send a signal to the expected thread to tell this thread that it needs to process a Notification. After receiving the signal, the specified thread removes the Notification from the queue and processes it.

The official documentation has given sample code, which is borrowed here to test the actual results:

Code Listing 2: Posting and forwarding a Notification in different threads

 @interface ViewController () <NSMachPortDelegate> 
 
 @property (nonatomic) NSMutableArray *notifications; // Notification queue  
 @property (nonatomic) NSThread *notificationThread; // expected thread  
 @property (nonatomic) NSLock *notificationLock; // Lock object used to lock the notification queue to avoid thread conflicts  
 @property (nonatomic) NSMachPort *notificationPort; // Communication port used to send signals to the desired thread   
 
 @end   
 
 @implementation ViewController 
 
 - ( void )viewDidLoad {
 [ super viewDidLoad]; 
 
 NSLog(@ "current thread = %@" , [NSThread currentThread]); 
 
 // Initialization  
 self.notifications = [[NSMutableArray alloc] init];
 self.notificationLock = [[NSLock alloc] init]; 
 
 self.notificationThread = [NSThread currentThread];
 self.notificationPort = [[NSMachPort alloc] init];
 self.notificationPort.delegate = self; 
 
 // Add the port source to the run loop of the current thread  
 // When a Mach message arrives and the receiving thread's run loop is not running, the kernel saves the message until the next time it enters the run loop  
 [[NSRunLoop currentRunLoop] addPort:self.notificationPort
 forMode:(__bridge NSString *)kCFRunLoopCommonModes]; 
 
 [[NSNotificationCenter defaultCenter] addObserver:self selector: @selector (processNotification:) name:@ "TestNotification" object:nil]; 
 
 dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0 ), ^{ 
 
 [[NSNotificationCenter defaultCenter] postNotificationName:TEST_NOTIFICATION object:nil userInfo:nil]; 
 
 });
 } 
 
 - ( void )handleMachMessage:( void *)msg { 
 
 [self.notificationLock lock]; 
 
 while ([self.notifications count]) {
 NSNotification *notification = [self.notifications objectAtIndex: 0 ];
 [self.notifications removeObjectAtIndex: 0 ];
 [self.notificationLock unlock];
 [self processNotification:notification];
 [self.notificationLock lock];
 }; 
 
 [self.notificationLock unlock];
 } 
 
 - ( void )processNotification:(NSNotification *)notification { 
 
 if ([NSThread currentThread] != _notificationThread) {
 // Forward the notification to the correct thread.  
 [self.notificationLock lock];
 [self.notifications addObject:notification];
 [self.notificationLock unlock];
 [self.notificationPort sendBeforeDate:[NSDate date]
 components:nil
 from:nil
 reserved: 0 ];
 }
 else {
 // Process the notification here;  
 NSLog(@ "current thread = %@" , [NSThread currentThread]);
 NSLog(@ "process notification" );
 }
 } 
 
 @end  

After running, the output is as follows:

 2015-03-11​​​​   23 : 38 : 31.637 test[ 1474 : 92483 ] current thread = <NSThread: 0x7ffa4070ed50 >{number = 1 , name = main}
 2015-03-11​​​​   23 : 38 : 31.663 test[ 1474 : 92483 ] current thread = <NSThread: 0x7ffa4070ed50 >{number = 1 , name = main}
 2015-03-11​​​​   23 : 38 : 31.663 test[ 1474 : 92483 ]process notification

As you can see, the Notification we threw in the global dispatch queue was received in the main thread as expected.

For the specific analysis and limitations of this implementation, please refer to the official document Delivering Notifications To Particular Threads. Of course, a better way may be to subclass NSNotificationCenter ourselves, or write a separate class to handle this forwarding.
Thread safety of NSNotificationCenter

Apple's strategy of posting and forwarding the same message in the same thread is probably based on thread safety considerations. The official documentation tells us that NSNotificationCenter is a thread-safe class, and we can use the same NSNotificationCenter object in a multi-threaded environment without locking. The original text is in the Threading Programming Guide, as follows:

 The following classes and functions are considered generally to be thread-safe. You can use the same instance from multiple threads without first acquiring a lock. 
 
 NSArray
 ...
 NSNotification
 NSNotificationCenter

We can add/remove notification observers in any thread, and we can post a notification in any thread.

NSNotificationCenter has done a lot of work in terms of thread safety, does that mean we can sit back and relax? Let's go back to the last example and modify it a little bit, step by step:

Code Listing 3: Common pattern for NSNotificationCenter

 @interfaceObserver : NSObject 
 
 @end   
 
 @implementation Observer 
 
 - (instancetype)init
 {
 self = [ super init]; 
 
 if (self)
 {
 _poster = [[Poster alloc] init]; 
 
 [[NSNotificationCenter defaultCenter] addObserver:self selector: @selector (handleNotification:) name:TEST_NOTIFICATION object:nil]
 } 
 
 return self;
 } 
 
 - ( void )handleNotification:(NSNotification *)notification
 {
 NSLog(@ "handle notification " );
 } 
 
 - ( void )dealloc
 {
 [[NSNotificationCenter defaultCenter] removeObserver:self];
 } 
 
 @end   
 
 // Other places  
 [[NSNotificationCenter defaultCenter] postNotificationName:TEST_NOTIFICATION object:nil];

The above code is what we usually do: add a notification listener, define a callback, and remove the listener when the object to which it belongs is released; then post a notification somewhere in the program. Simple and clear, if all this happens in one thread, or at least the dealloc method is run in the thread of -postNotificationName: (Note: NSNotification post and forward are synchronous), then everything is OK, there is no thread safety problem. But what problems will arise if the dealloc method and -postNotificationName: method are not run in the same thread?

Let's modify the above code again:

Code Listing 4: Thread safety issues caused by NSNotificationCenter

 #pragma mark - Poster 
 
 @interface Poster : NSObject 
 
 @end   
 
 @implementation Poster 
 
 - (instancetype)init
 {
 self = [ super init]; 
 
 if (self)
 {
 [self performSelectorInBackground: @selector (postNotification) withObject:nil];
 } 
 
 return self;
 } 
 
 - ( void )postNotification
 {
 [[NSNotificationCenter defaultCenter] postNotificationName:TEST_NOTIFICATION object:nil];
 } 
 
 @end   
 
 #pragma mark - Observer 
 
 @interfaceObserver : NSObject
 {
 Poster *_poster;
 } 
 
 @property (nonatomic, assign) NSInteger i; 
 
 @end   
 
 @implementation Observer 
 
 - (instancetype)init
 {
 self = [ super init]; 
 
 if (self)
 {
 _poster = [[Poster alloc] init]; 
 
 [[NSNotificationCenter defaultCenter] addObserver:self selector: @selector (handleNotification:) name:TEST_NOTIFICATION object:nil];
 } 
 
 return self;
 } 
 
 - ( void )handleNotification:(NSNotification *)notification
 {
 NSLog(@ "handle notification begin" );
 sleep( 1 );
 NSLog(@ "handle notification end" ); 
 
 self.i = 10 ;
 } 
 
 - ( void )dealloc
 {
 [[NSNotificationCenter defaultCenter] removeObserver:self]; 
 
 NSLog(@ "Observer dealloc" );
 } 
 
 @end   
 
 #pragma mark - ViewController 
 
 @implementation ViewController 
 
 - ( void )viewDidLoad {
 [ super viewDidLoad]; 
 
 __autoreleasing Observer *observer = [[Observer alloc] init];
 } 
 
 @end  

This code adds a TEST_NOTIFICATION notification listener to the main thread and removes it from the main thread, while our NSNotification is posted in the background thread. In the notification processing function, we let the callback thread sleep for 1 second and then set the property i value. What will happen at this time? Let's take a look at the output first:

 2015-03-14​​​​   00 : 31 : 41.286 SKTest[ 932 : 88791 ] handle notification begin
 2015-03-14​​​​   00 : 31 : 41.291 SKTest[ 932 : 88713 ] Observer dealloc
 2015-03-14​​​​   00 : 31 : 42.361 SKTest[ 932 : 88791 ] handle notification end
 (lldb) 
 
 // The program throws "Thread 6: EXC_BAD_ACCESS (code=EXC_I386_GPFLT)" at self.i = 10  

A classic memory error, the program crashed. In fact, from the output, we can see what happened. Let's briefly describe:

When we register an observer, the notification center holds a weak reference to the observer to ensure that the observer is available.
The main thread calls the dealloc operation, which reduces the reference count of the Observer object to 0, and the object will be released.
The background thread sends a notification. If the Observer has not been released at this time, it will forward the message to it and execute the callback method. If the object is released during the callback execution, the above problem will occur.

Of course, the above example is intentional, but it does not rule out the possibility of encountering similar problems in actual coding. Although NSNotificationCenter is thread-safe, it does not mean that we can guarantee thread safety when using it. If we are not careful, thread problems will still occur.

So what should we do? Here are some good suggestions:

Try to handle notification-related operations in one thread. In most cases, this will ensure that notifications work properly. However, we cannot be sure in which thread the dealloc method will be called, so this is still difficult.
When registering listeners, use a block-based API. In this way, if we continue to call properties or methods of self in the block, we can handle it in a weak-strong way. You can modify the above code to see what the effect is.
Use objects with a safe lifecycle, which is perfect for singleton objects, as they will not be released during the entire lifecycle of the application.
Use a proxy.