I need to run 3 methods one after each other in a seperate thread that calls an api (NSURLSessionDataTask async). I have looked into dispatch groups but this seems to run method 1 and 2 at the same time and then runs method 3 when they finish:
dispatch_group_t group = dispatch_group_create();
//METHOD 1
dispatch_group_enter(group);
[self method1WithCompletion:^(BOOL success){
dispatch_group_leave(group);
}];
//METHOD 2
dispatch_group_enter(group);
[self method2WithCompletion:^(BOOL success){
dispatch_group_leave(group);
}];
dispatch_group_notify(group,dispatch_get_main_queue(),^{
//METHOD 3
});
I need it to run method 1 and when that completes run method 2, and when that completes finally run method 3 (queue the methods).
I know I could chain the methods on each completion to run the next but I thought there would be a better approach to this...any ideas?
You are close.
dispatch_group_enter and company only handle the bit that makes it so everything that dispatch_group_enters into the dispatch_group_t will complete before calling the block passed into dispatch_group_notify.
So we can use them to good use when waiting for tasks. Rather than having just 1 group that waits for every task to finish, we can use a group for each asynchronous task that needs to be completed:
// You can get a global queue or create your own, it doesn't really matter
dispatch_queue_t queue = dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);
// Create a group for each task you want to wait for
dispatch_group_t group1 = dispatch_group_create();
dispatch_group_t group2 = dispatch_group_create();
// Call your first task on the first group
dispatch_group_enter(group1);
[self method1WithCompletion:^(BOOL success){
// Task is completed, so signal that it has finished
dispatch_group_leave(group1);
}];
// Call your 2nd task on the 2nd group
dispatch_group_enter(group2);
// Make the second task wait until group1 has completed before running
dispatch_group_notify(group1, queue, ^{
// METHOD 2
[self method2WithCompletion:^(BOOL success){
// Signal to the group that the task has completed
dispatch_group_leave(group2);
}];
});
// Nothing is waiting on the 3rd task, so no need to create a group for it
dispatch_group_notify(group2,dispatch_get_main_queue(),^{
//METHOD 3
// Do whatever you need to do in here
});
Here is some more information about Dispatch Queues and how you can use them.
Edit: Sorry, I completely changed my answer. Once you left your comment, it hit me that the tasks you were calling were asynchronous, and using a serial dispatch_queue_t would not make a difference! (The blocks are run serially, but method2 would be run immediately after method1, not wait for completion)
EDITED: I don't think so anymore, cjwirth have refuted my assumption below in comments
I think there still can be approach with serial queue (But it's only supposition, I didn't check it). The main idea is to dispatch group's task into serial queue, with using dispatch_group_enter(group) before dispatch and dispatch_group_leave(group) on your method1..2 completes. Let me show what it's supposed to be:
dispatch_queue_t queue = dispatch_queue_create("com.example.MyQueue", NULL);
dispatch_group_t group = dispatch_group_create();
//METHOD 1
dispatch_group_enter(group);
dispatch_group_async(group, queue, ^{
[self method1WithCompletion:^(BOOL success){
dispatch_async(queue, ^{
dispatch_group_leave(group);
});
}];
});
//METHOD 2
dispatch_group_enter(group);
dispatch_group_async(group, queue, ^{
[self method2WithCompletion:^(BOOL success){
dispatch_async(queue, ^{
dispatch_group_leave(group);
});
}];
});
dispatch_group_notify(group,dispatch_get_main_queue(),^{
//METHOD 3
});
NOTE: This kind of implementation looks like something wrong. As we had NSOperationQueue already, so I would recommend you to wrap your NSURLSessionDataTask's stuff into NSOperation and perform them sequentially
Related
I am aware that calling dispatch_async in the current queue will cause a deadlock, however, experiencing a deadlock in a completely different queue:
-(void) deadlock{
// we reach this point in the main queue
dispatch_sync(dispatch_queue_create("lucas", 0), ^{
NSLog(#"Doing something in the bakcgound...");
// We reach this point in another queue, but it deadlocks!
dispatch_sync(dispatch_get_main_queue(), ^{
NSLog(#"Will I ever get here?????");
});
});
}
Any idea of what I'm doing wrong??
Yes, it's a deadlock. Just like you have been creating an example of one
-(void) deadlock{
// we reach this point in the main queue
//and so main queue waits till this task will finish
dispatch_sync(dispatch_queue_create("lucas", 0), ^{
//doing something in background
//while main queue still blocked by that dispatch_sync() call
NSLog(#"Doing something in the bakcgound...");
// We reach this point in another queue, but it deadlocks!
//Of cause it does!!! Main queue is still waiting till task dispatched to "lucas" queue synchronously finishes. But it can't - waits for main queue to perform this later bock synchronously
dispatch_sync(dispatch_get_main_queue(), ^{
NSLog(#"Will I ever get here?????");
});
});
}
//we reach this point only after all code written above will performed. so, in our case, this point is unreachable either way
So, dependently on your task, you should change one of this dispatch_sync() to dispatch_async().
Dispatch_sync is semantically equivalent to a traditional mutex lock, rather than creating a thread. Try the following, will give you: "Is main thread: 1".
dispatch_sync(dispatch_queue_create("lucas", 0), ^{
NSLog(#"Doing something in the bakcgound...");
NSLog(#"Is main thread: %d", [NSThread isMainThread]);
// We reach this point in another queue, but it deadlocks!
dispatch_sync(dispatch_get_main_queue(), ^{
NSLog(#"Will I ever get here?????");
});
});
What you want I think is more or less the following:
dispatch_async(dispatch_get_global_queue( DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^(void){
NSLog(#"Doing something in the bakcgound...");
dispatch_async(dispatch_get_main_queue(), ^(void){
NSLog(#"Will I ever get here?????");
});
});
I have a series of dispatch_async that I am performing and I would like to only update the UI when they are all done. Problem is the method within dispatch_async calls something in a separate thread so it returns before the data is fully loaded and dispatch_group_notify is called before everything is loaded.
So I introduce a infinite loop to make it wait until a flag is set.
Is this the best way? See code below.
dispatch_queue_t queue = dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_HIGH, 0);
dispatch_group_t group = dispatch_group_create();
for (...) {
dispatch_group_async(group, queue, ^{
__block BOOL dataLoaded = NO;
[thirdPartyCodeCallWithCompletion:^{
dataLoaded = YES;
}];
// prevent infinite loop
dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(1.0 * NSEC_PER_SEC)),
queue, ^{
dataLoaded = YES;
});
// infinite loop to wait until data is loaded
while (1) {
if (dataLoaded) break;
}
}
dispatch_group_notify(group, dispatch_get_main_queue(), ^{
//update UI
});
}
You're already aware of dispatch groups. Why not just use dispatch_group_wait(), which includes support for a timeout? You can use dispatch_group_enter() and dispatch_group_leave() rather than dispatch_group_async() to make the group not done until the internal block for the third-party call with completion is finished.
dispatch_queue_t queue = dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_HIGH, 0);
dispatch_group_t group = dispatch_group_create();
for (...) {
dispatch_group_enter(group);
dispatch_async(queue, ^{
[thirdPartyCodeCallWithCompletion:^{
dispatch_group_leave(group);
}];
}
}
dispatch_group_wait(group, dispatch_time(DISPATCH_TIME_NOW, NSECS_PER_SEC));
dispatch_async(dispatch_get_main_queue(), ^{
//update UI
});
The use of dispatch_group_wait() does make this code synchronous, which is bad if run on the main thread. Depending on what exactly is supposed to happen if it times out, you could use dispatch_group_notify() as you were and use dispatch_after() to just updates the UI rather than trying to pretend the block completed.
Update: I tweaked my code to make sure that "update UI" happens on the main queue, just in case this code isn't already on the main thread.
By the way, I only used dispatch_async() for the block which calls thirdPartyCodeCallWithCompletion: because your original used dispatch_group_async() and I wasn't sure that the hypothetical method was asynchronous. Most APIs which take a completion block are asynchronous, though. If that one is, then you can just invoke it directly.
Another method is to use semaphore and the dispatch_semaphore_wait:
// Create your semaphore, 0 is specifying the initial pool size
dispatch_semaphore_t semaphore = dispatch_semaphore_create(0);
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
#autoreleasepool {
// Your code goes here
}
// Release the resource and signal the semaphore
dispatch_semaphore_signal(semaphore);
});
// Wait for the above block execution, AKA Waits for (decrements) a semaphore.
dispatch_semaphore_wait(semaphore, DISPATCH_TIME_FOREVER);
// After this line you can now safely assert anything you want regarding the async operation since it is done.
I'm executing two asynchronous methods, both answering through blocks. I have to wait for both blocks to be called before I call a third one. Using dispatch_group would work if my methods were synchronous, but I don't want to change them, since it would require lots of code refactoring.
Better explaining the problem:
[myLib doTask1:^{
// do stuff when task1 is done
}];
[myLib doTask2:^{
// do stuff when task2 is done
}];
And then I'd like to do something like:
[self executeThisWhenBothTasksDone:^{
// do stuff after both tasks are done
}
dispatch_group_enter and dispatch_group_leave would help you. The least code change might be this.
dispatch_group_t group = dispatch_group_create();
dispatch_group_enter(group);
[myLib doTask1:^{
// do stuff when task1 is done
dispatch_group_leave(group);
}];
dispatch_group_enter(group);
[myLib doTask2:^{
// do stuff when task2 is done
dispatch_group_leave(group);
}];
dispatch_group_notify(group, dispatch_get_main_queue(), ^{
[self executeThisWhenBothTasksDone:^{
// do stuff after both tasks are done
}
});
You can use dispatch_group_async and dispatch_group_notify to get this behavior for non-synchronous methods
I have a method that I add to a GCD queue that I have created (so it's a serial queue) and then run it async. From within that block of code I make a dispatch to the main queue, when that block of code dispatched to the main queue is complete I set a BOOL flag to YES, so that I further down in my code can check if this condition is YES then I can continue to the next method. Here is the code in short:
dispatch_queue_t queue = dispatch_queue_create("ProcessSerialQueue", 0);
dispatch_async(queue, ^{
Singleton *s = [Singleton sharedInstance];
dispatch_sync(dispatch_get_main_queue(), ^{
[s processWithCompletionBlock:^{
// Process is complete
processComplete = YES;
}];
});
});
while (!processComplete) {
NSLog(#"Waiting");
}
NSLog(#"Ready for next step");
However this does not work, because dispatch_sync is never able to run the code on the main queue. Is this because I'm running a while loop on the main queue (rendering it busy)?
However if I change the implementation of the while loop to this:
while (!processComplete) {
NSLog(#"Waiting")
NSDate *date = [NSDate distantFuture];
[[NSRunLoop currentRunLoop] runMode:NSDefaultRunLoopMode beforeDate:date];
}
It works without a glitch. Is this an acceptable solution for this scenario? Can I do it any other preferred way? What kind of magic stuff does NSRunLoop do? I need to understand this better.
Part of the main thread's NSRunLoop job is to run any blocks queued on the main thread. By spinning in a while-loop, you're preventing the runloop from progressing, so the queued blocks are never run unless you explicitly make the loop run yourself.
Runloops are a fundemental part of Cocoa, and the documentation is pretty good, so I'd reccommend reading it.
As a rule, I'd avoid manually invoking the runloop as you're doing. You'll waste memory and make make things complicated very quickly if you have multiple manual invocations running on top of one another.
However, there is a much better way of doing this. Split your method into a -process and a -didProcess method. Start the async operation with your -process method, and when it completes, call -didProcess from the completion block. If you need to pass variables from one method to the other, you can pass them as arguments to your -didProcess method.
Eg:
dispatch_queue_t queue = dispatch_queue_create("ProcessSerialQueue", 0);
dispatch_async(queue, ^{
Singleton *s = [Singleton sharedInstance];
dispatch_sync(dispatch_get_main_queue(), ^{
[s processWithCompletionBlock:^{
[self didProcess];
}];
});
});
You might also consider making your singleton own the dispatch queue and make it responsible for handling the dispatch_async stuff, as it'll save on all those nasty embedded blocks if you're always using it asynchronously.
Eg:
[[Singleton sharedInstance] processAyncWithCompletionBlock:^{
NSLog(#"Ready for next step...");
[self didProcess];
}];
Doing something like what you posted will most likely freeze the UI. Rather than freezing up everything, call your "next step" code in a completion block.
Example:
dispatch_queue_t queue = dispatch_queue_create("ProcessSerialQueue", 0);
dispatch_queue_t main = dispatch_get_main_queue();
dispatch_async(queue, ^{
Singleton *s = [Singleton sharedInstance];
dispatch_async(dispatch_get_main_queue(), ^{
[s processWithCompletionBlock:^{
// Next step code
}];
});
});
Don't go creating a loop like that waiting for a value inside a block, variables in blocks are read only, instead call your completion code from inside the block.
dispatch_async(queue, ^{
Singleton *s = [Singelton sharedInstance];
[s processWithCompletionBlock:^{
//process is complete
dispatch_sync(dispatch_get_main_queue(), ^{
//do something on main queue....
NSLog(#"Ready for next step");
});
}];
});
NSLog(#"waiting");
I'm trying to perform the acquisition of data from the internet on the load of my view. To not lag the UI, I'm performing the HTML download and parsing by using
[self performSelectorInBackground:#selector(alertThreadMethod) withObject:nil];
which checks to see if there is an alert online. In order to display the information on the view however, iOS says that I need to use the main thread. So i call the display code right after:
[self performSelectorInBackground:#selector(alertThreadMethod) withObject:nil];
[self loadAlert];
In doing this, the [self loadAlert]; actually runs before the selector in the background (it is faster). Because of this, it does not have the information that the selector in the background is supposed to provide it.
How can I ensure that [self loadAlert]; runs after? Or is there a better way to do this?
You can either move loadAlert invocation into the alertThreadMethod or use Grand Central Dispatch serial queues, e.g.,
dispatch_queue_t queue = dispatch_queue_create("com.example.MyQueue", NULL);
dispatch_async(queue, ^{
[self alertThreadMethod];
[self loadAlert];
});
dispatch_release(queue);
Or, if loadAlert is updating the UI, since you do UI updates in the main queue, you'd do something like:
dispatch_queue_t queue = dispatch_queue_create("com.example.MyQueue", NULL);
dispatch_async(queue, ^{
[self alertThreadMethod];
dispatch_async(dispatch_get_main_queue(), ^{
[self loadAlert];
});
});
dispatch_release(queue);
By the way, if you're just doing this one task in background, rather than creating your own serial queue, you might just use one of the existing background queues. You only need to create a queue if you need the serial nature (i.e. you're going to be numerous dispatch_async calls and you can't have them running concurrently). But in this simple case, this might be even a little more efficient, bypassing the creating and releasing of the serial queue:
dispatch_queue_t queue = dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);
dispatch_async(queue, ^{
[self alertThreadMethod];
dispatch_async(dispatch_get_main_queue(), ^{
[self loadAlert];
});
});
In your alertThreadMethod, after you have your information, call the method performSelectorOnMainThread:withObject:waitUntilDone: and pass it a selector to your loadAlert method.
-(void)alertThreadMethod
{
// get your information here
performSelectorOnMainThread:#selector(loadAlert) withObject:nil waitUntilDone:NO
}