I'm displaying a table with some data to the user. As soon as the view is presented, I'm making a web call to see if there's updated data (asynchronously). When the service call returns, I'd like to update my core data and the view.
Unfortunately I'm often getting dead locks because the view reads the same data as the service call writes. How can I solve this?
When I pause the simulator as soon as it's frozen, the waiting threads are waiting at the following places:
Background (updating) thread: (psynch_cvwait)
[mainContext performSelectorOnMainThread:#selector(mergeChangesFromContextDidSaveNotification:)
withObject:notification
waitUntilDone:YES];
Main thread: (psynch_mutexwait)
performing a filteredArrayUsingPredicate
Thanks a lot!
-mergeChangesFromContextDidSaveNotification: will block the main thread. That call will lock both NSManagedObjectContext instances while it updates the main context with the changes being passed in.
This is generally considered unavoidable in pre-iOS 5 applications. You can minimize it by making more frequent, smaller, saves but it is still going to happen.
The only other option for pre-iOS 5 applications is to tell the main context to -reset: but that will require re-fetching everything -- another delay.
It looks like the main thread is trying to grab some low level lock that the background thread already has (or vice versa). Are you using #synchronized somewhere to provide mutex?
Anyway, is there any reason why your background thread needs to wait for -mergeChangesFromContextDidSaveNotification: to complete? If not, pass NO as the last parameter.
I had the same problem (lock on psynch_cvwait) when I was merging context changes (both ways) between the main and a background context (both using NSConfinementConcurrencyType). The problem was caused by subscribing to NSManagedObjectContextDidSaveNotification on a different queue from which it was sent:
[[NSNotificationCenter defaultCenter]
addObserverForName:NSManagedObjectContextDidSaveNotification
object:mainContext
queue:bgQueue
usingBlock:^(NSNotification * _Nonnull note) {
// bgContext runs on bgQueue
[bgContext mergeChangesFromContextDidSaveNotification:note];
}]
As a result the block was never called, and both main and background queues hung on psynch_cvwait()
I fixed it by not blocking mainContext's queue:
[[NSNotificationCenter defaultCenter]
addObserverForName:NSManagedObjectContextDidSaveNotification
object:mainContext
queue:nil
usingBlock:^(NSNotification * _Nonnull note) {
[bgQueue addOperationWithBlock:^{
[bgContext mergeChangesFromContextDidSaveNotification:note];
}];
}]
However, it doesn't seem to be a problem if I block the background queue when merging changes into the main context.
Related
I want to build an NSOperation that has a timeout of 10 seconds after it begins and could be ended by another thread at any point through an event. I also use an NSOperationQueue for managing more operations like this and it can only compute one at a time(maxConcurrentOperationCount = 1). For this I have thought about an implementation using dispatch_semaphore's as it follows:
#implementation CustomOperation
dispatch_semaphore_t semaphore;
-(void) main {
#autoreleasepool {
[[NSNotificationCenter defaultCenter] addObserver:self selector:#selector(shouldFinishWaiting:) name:#"myCustomEvent" object:nil];
semaphore = dispatch_semaphore_create(0);
[self doStuff];
dispatch_semaphore_wait(semaphore, dispatch_time(DISPATCH_TIME_NOW, (int64_t)(10 * NSEC_PER_SEC)));
[[NSNotificationCenter defaultCenter] removeObserver:self name:#"myCustomEvent" object:nil];
}
}
-(void) shouldFinishWaiting {
NSLog(#"[WatchOperation]: Should finish waiting! %#", self);
dispatch_semaphore_signal(semaphore);
}
#end
The problem I have is that once in many times when an user starts the application the first operation would not finish until the event gets triggered(and this could happen after 30 mins). The timeout would not be taken in consideration. I noticed this on logs from some users so I wasn't able to reproduce it. What could go wrong so that the dispatch_semaphore_wait fails to execute?
Later edit: I mistakenly thought that the -doStuff is async. It seems it is not.I replaced it with:
dispatch_async(dispatch_get_global_queue(QOS_CLASS_USER_INITIATED, 0), ^{
[self doStuff];
});
, but the operation was already on the serial queue 'user initiated'. As I can see it creates another concurent thread, will that happen every time? Is this safe?
I don't think dispatch semaphore can go wrong. Maybe your -doStuff is taking too much time. Make sure you are doing the following:
1. The method [self doStuff]; is async and it dispatches to a DIFFERENT thread than the current one (dispatching to current thread doesn't really make sense if you want the 10 second timeout using the semaphore).
2. Make sure you keep checking for self.isCancelled in -doStuff.
Also, I would suggest that you take a slightly different design approach for your requirements (if I understand them correctly) --
1. Your NSOperation can always be cancelled from any external thread my calling cancel on the object, so there is no need for a complex NSNotification-based approach, just check for isCancelled and override the -cancel method.
2. For the 10 second timeout, you can use the semaphore approach, but just have a DIFFERENT thread doing the semaphore wait. That thread can then cancel your task from within after 10 seconds.
I assume your semaphore won't stay a global variable...
Depending on whether you are using 32 or 64 bit, NSEC_PER_SEC could be a 32 bit value, which overflows and turns into something negative when multiplied by 10. Replace 10 by 10.0. Might fix the problem, might not do anything at all.
#selector(shouldFinishWaiting:) should be #selector (shouldFinishWaiting). No colon because the method has no arguments.
I am trying to do window management, but I need the code running on a separate thread.
The first thing I need to do is subscribe to app notifications like this:
NSNotificationCenter *nc = [[NSWorkspace sharedWorkspace] notificationCenter];
NSString *not = NSWorkspaceDidLaunchApplicationNotification;
[nc addObserver:self selector:#selector(appLaunched:) name:not object:nil];
But if I simply call addObserver on another thread, will the notifications be delivered there instead?
Apple has this reference, but it seems overcomplicated:
https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/Notifications/Articles/Threading.html
If the answer to the first question is no, then why couldn't I just forward the message like this?
NSThread *other;
- (void)appLaunched:(NSNotification*)not {
if([NSThread currentThread] != otherThread)
[self performSelector:#selector(appLaunched:) onThread:other withObject:not waitUntilDone:NO];
else
// do respond to notification
}
The second thing I need to do is add an AXObserver to a runloop on the other thread.
If I call CFRunLoopGetCurrent() from another thread, will a run loop automatically be created like calling [NSRunLoop currentRunLoop] or do a I have to create one?
Observers which are registered using -addObserver:selector:name:object: receive the notification on the thread where it's posted, not where they registered. There's also -addObserverForName:object:queue:usingBlock:, which causes the notification to be received on the specified queue, but that doesn't let you make it arrive on a specified background thread. (Only the main queue is tied to a thread.)
You can shunt a notification to another thread in the manner you suggest. However, the original receiving thread has to be idling to receive the notification in the first place. Or, rather, it has to be idling in order to allow NSWorkspace to detect the condition which causes it to post the notification.
All threads create a runloop for themselves as soon as it's requested. It's basically impossible to observe a thread not having a runloop, so you might as well just act as though the runloop is created when the thread is created.
All of that said, your original goal – "I am trying to do window management, but I need the code running on a separate thread" – is problematic. Many GUI manipulations are not legal from background threads. Also, why do you "need" to do it from a background thread? And if your main thread is not free, you're not going to receive the workspace notifications in the first place.
I am looking for a better way to do this, if possible.
I have an asynchronous callback that updates a local sqlite database. I set a flag in a singleton variable (archiveUpdateComplete) when the update completes. I sleep in a do-while until the flag gets set to true, then I hydrate my tableview. Would like to remove sleep()! Thanks for any suggestions.
#define kBgQueue dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT,0)
- (void)viewDidLoad
{
dispatch_async(kBgQueue, ^{
//Hydrate word archive table view
do {
sleep(1.0);
} while ([sharedManager archiveUpdateComplete]==NO);
[self performSelectorOnMainThread:#selector(hydrateWordArchive) withObject:nil waitUntilDone:YES];
//Run custom activity indicator
dispatch_async(dispatch_get_main_queue(), ^{
[MBProgressHUD hideHUDForView:self.view animated:YES];
});
});
}
If you need to poll
Polling/sleeping is rarely necessary or good. As an alternative:
You can attach an NSTimer to the main thread's run loop.
The selector the timer calls can test [sharedManager archiveUpdateComplete]
if YES is returned, then
invalidate the timer
call [MBProgressHUD hideHUDForView:self.view animated:YES];
If you don't need to poll
There are a few immediate alternatives. Which you choose depends on what knows about what:
If your manager knows who to message following completion, then the manager can simply message it. If that must occur on the main thread you can use -[NSObject performSelectorOnMainThread:withObject:waitUntilDone:] to forward to the main thread. You may also see this approach with delegates. In the case of a singleton, it doesn't make a lot of sense to take this route.
If your manager does not know who is interested in the change/completion, your manager can post a NSNotification after the task has finished (on the current thread or from the main thread).
Key Value Observing (KVO) is another option.
Perhaps I'm missing something, but why don't you just use a completion callback for this?
In other words, you change your computation to "think" in terms of nested blocks. The first async block (on some concurrent queue) does the work of updating the database, and when it's done it dispatches another async block (to the same concurrent queue) which hydrates the tableview. Finally, from that block you dispatch_async yet another block on the main queue which updates the UI, since that's the only bit that needs to execute on the main queue.
Rather than poll, in other words, you want to chain your async operations. See COMPLETION CALLBACKS section of the man page for dispatch_async().
I was having problems modifying a view inside a thread. I tried to add a subview but it took around 6 or more seconds to display. I finally got it working, but I don't know how exactly. So I was wondering why it worked and what's the difference between the following methods:
This worked -added the view instantly:
dispatch_async(dispatch_get_main_queue(), ^{
//some UI methods ej
[view addSubview: otherView];
}
This took around 6 or more seconds to display:
[viewController performSelectorOnMainThread:#selector(methodThatAddsSubview:) withObject:otherView
waitUntilDone:NO];
NSNotification methods - took also around 6 seconds to display the observer was in the viewController I wanted to modify paired to a method to add a subview.
[[NSNotificationCenter defaultCenter] postNotificationName:
#"notification-identifier" object:object];
For reference these were called inside this CompletionHandler of the class ACAccountStore.
accountStore requestAccessToAccountsWithType:accountType withCompletionHandler:^(BOOL granted, NSError *error) {
if(granted) {
// my methods were here
}
}
By default, -performSelectorOnMainThread:withObject:waitUntilDone: only schedules the selector to run in the default run loop mode. If the run loop is in another mode (e.g. the tracking mode), it won't run until the run loop switches back to the default mode. You can get around this with the variant -performSelectorOnMainThread:withObject:waitUntilDone:modes: (by passing all the modes you want it to run in).
On the other hand, dispatch_async(dispatch_get_main_queue(), ^{ ... }) will run the block as soon as the main run loop returns control flow back to the event loop. It doesn't care about modes. So if you don't want to care about modes either, dispatch_async() may be the better way to go.
It's likely because performSelectorOnMainThread:withObject:waitUntilDone: queues the message with common run loop modes. According to Apple's Concurrency Programming Guide, the main queue will interleave queued tasks with other events from the app's run loop. Thus, if there are other events to be processed in the event queue, the queued blocks in the dispatch queue may be run first, even though they were submitted later.
This article is a superb explanation to performSelectorOnMainThread vs. dispatch_async, which also answers the above question.
Did you try thePerformSelectorOnMainThread with waitUntilDone=YES
Eg:
Code:
[viewController performSelectorOnMainThread:#selector(methodThatAddsSubview:) withObject:otherView waitUntilDone:YES];
I think that might solve the issue as of why the PerformSelectorOnMainThread takes so long to respond.
I understand that Core Data is not thread safe and that NSManagedObjectContext and NSManagedObjects associated with a context cannot be passed from thread to thread.
Question:
However, if I have a NSManagedObjectContext on my main thread, can I create a NSManagedObject object on a background thread (WITHOUT attaching it to any context -- that is, simply call alloc/init on NSManagedObject), then pass that NSManagedObject back to the main thread and add it to the context from there? I've reviewed the docs on Core Data concurrency, but can't find anything that says this usage pattern is okay.
Context:
I have a background thread that performs a complex task and then publishes a result. The result is an NSManagedObject subclass that contains a few attributes: time, a file path, and a success or error message (as a string). I want to create the result object on the background thread, then toss it back to the main thread and add it to the Core Data context where it will be displayed in a tableView.
If I can't create the managedObject on the background thread, then I'll need to create a dictionary, pass the dictionary to the main thread, read the keys, create the managedObject from those values, etc. Just seems cleaner to create the managedObject on the background thread if possible.
The better approach is to have a context per thread. This way each thread will have its own scratch pad to play around with. Then when you background thread finishes, tell your main thread to update its view or ui table view or how every you are presenting your data.
You'll need to notify your main thread when changes occur. The big problem is, the contexts between different threads and main thread are not aware of each other. There is a way in core data to keep the contexts in sync. When you want to save, the context on the background thread should broadcast an NSManagedObjectContextDidSaveNotification notification.
So for example, in your main method in your NSOperation, you could do this:
NSNotificationCenter *nc = [NSNotificationCenter defaultCenter];
[nc addObserver:self
selector:#selector(mergeChanges:)
name:NSManagedObjectContextDidSaveNotification
object:context];
the mergeChanges would be a private method in your NSOperation instance.
example of merge changes
- (void)mergeChanges:(NSNotification *)notification
{
ApplicationController *appController = [[NSApplication sharedApplication] delegate];
NSManagedObjectContext *mainContext = [appController managedObjectContext];
// Merge changes into the main context on the main thread
[mainContext performSelectorOnMainThread:#selector(mergeChangesFromContextDidSaveNotification:)
withObject:notification
waitUntilDone:YES];
}