From Main UIViewController I call
if (required) [dataDB function];
next command;
....
....
in the Database UIViewController
- (void) Function {
Display Alert Message for Processing;
performs steps (takes some time)
....
....
Close Alert Message
}
Although one should NOT block code
I need the [dataDB Function] to complete before next command is called;
Yet I need the Alert to start showing before perform steps starts.
Currently Alert appears after [dataDB Function] completes and closes almost immediately.
Please help.
try this code
if (required)
{
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
[dataDB function];
dispatch_async(dispatch_get_main_queue(), ^{
next command;
});
});
}
it will create async task of [dataDB function];and after competition of it, it will perform task on main queue of next command;
You want to use some combination of GCD dispatch queues and the completion block pattern.
You should use dispatch_async() to queue db functions to complete serially on a background queue (a non-concurrent one, so that they are executed in the order you dispatch them). Then you can show your alert on the main thread while you wait for operations to complete on the background queue. You can use a completion block that you pass to one of the background operations to call back to the main thread on completion, or use the dispatch_group_notify() functionality.
You could also consider using an NSOperationQueue, but I find just dispatching blocks to be much easier.
Related
I've a serial queue and I use that queue to call a performSelectorWithDelay like below
dispatch_async(serialQueue, ^(void) {
[self performSelector:#selector(fetchConfigFromNetwork) withObject:nil afterDelay:rootConfig.waitTime];
});
However, the method fetchConfigFromNetwork never gets called. However, if instead of serialQueue, I use mainQueue - it starts working.
Cannot understand what's happening here and how to fix it?
The explanation why your code doesn't work is in the documentation: https://developer.apple.com/documentation/objectivec/nsobject/1416176-performselector?language=occ
This method registers with the runloop of its current context, and
depends on that runloop being run on a regular basis to perform
correctly. One common context where you might call this method and end
up registering with a runloop that is not automatically run on a
regular basis is when being invoked by a dispatch queue. If you need
this type of functionality when running on a dispatch queue, you
should use dispatch_after and related methods to get the behavior you
want.
I'm assuming you want that method to be called on the serial queue with a delay. The most straight forward (and recommended way) is to use dispatch_after:
__weak typeof(self) wself = self;
dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(rootConfig.waitTime * NSEC_PER_SEC)), serialQueue, ^{
[wself fetchConfigFromNetwork];
});
This method sets up a timer to perform the aSelector message on the current thread’s run loop. The timer is configured to run in the default mode (NSDefaultRunLoopMode). When the timer fires, the thread attempts to dequeue the message from the run loop and perform the selector. It succeeds if the run loop is running and in the default mode; otherwise, the timer waits until the run loop is in the default mode.
This is the discussion about the method performSelector:withObject:afterDelay:, I think the block of dispatch_async will execute on a new thread (not main thread), but you would not know which thread it is, so you can not new a runloop and open it and assign it to this thread. because the runloop of thread is close in default except the main thread, the timer will wait forever.
On my opinion, you should use NSThread instead of dispatch_async, and create a runloop for the thread that you use, then specified the mode of runloop with NSDefaultRunLoopMode, if you actually want to cancelPreviousPerformRequestsWithTarget, otherwise use dispatch_after instead of performSelector.
That's my understanding. I can't promise it is right.
I've inherited a codebase that's using the following structure for threading:
dispatch_async(dispatch_get_main_queue(), { () -> Void in
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_HIGH, 0), { () -> Void in
//Several AFNetworking Server calls...
})
})
I'm not very experienced with threading, so I'm trying to figure out what the possible intention behind this structure. Why grab the main queue only to access another queue immediately? Is this a common practice? For a little more context, this code is executed in an UIApplicationDidBecomeActiveNotification notification, making several necessary service calls.
Is this structure safe? Essentially my goal is to make the service calls without blocking the UI. Any help or input is appreciated.
So I think this is an interesting few lines that somebody decided to write, so let's break down what's happening here (I may be breaking things down too much, sorry in advance, it just helps my own train of thought)
dispatch_async(dispatch_get_main_queue(), dispatch_block_t block)
This will put the block as a task on the main queue (which you the code is already running in), then immediately continue executing the code in the rest of the method (If he had wanted to wait for the block task to finish before continuing, he'd have made a dispatch_sync call instead).
The main queue is serial, so it will perform these tasks exactly in this order:
go ahead and execute the block after the end of the current method (the end of the run loop for the current task)
execute any other tasks that may have been asynchronously added to the main queue before you dispatch_async your block task into the queue
execute the block task
Now block just dispatches another task to the high priority global queue.
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_HIGH, 0), block2)
The DISPATCH_QUEUE_PRIORITY_HIGH is a concurrent queue-- so if you were to dispatch multiple tasks to this queue, it could potentially do them in parallel, depending on several system factors.
Your old co-worker wanted to make sure the networking calls in block2 were done ASAP
Because block is calling dispatch_async (which returns immediately), block task finishes, allowing the main queue to execute the next task in the queue.
The net result so far is that block2 is queued into the high priority global queue. After it executes, and your network calls complete, callback methods will be called and yadayada
...So what is the order of what's happening?
dispatch_async(dispatch_get_main_queue(), { () -> Void in
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_HIGH, 0), { () -> Void in
//Several AFNetworking Server calls...
})
})
//moreCode
1) moreCode executes
2) block executes (adds block2 with network calls onto global queue)
3/4) Next task in main queue executes
4/3) Network task in global queue executes
The order of which would happen first may vary between 3 and 4, but that's concurrency for you :)
So unless old coworker wanted moreCode to execute first before adding the network calls to a global queue, you can go ahead and remove that initial dispatch_async into the main queue.
Assuming it looks like they wanted the network calls done ASAP, there probably is no reason to delay the addition of those networking tasks into a global queue.
Open to any input ^^. My experience involves reading all of the documentation on GCD today, then deciding to look at some GCD tagged questions
I am reading a iOS book which says that "dispatch_sync function blocks the concurrent queue to which the block is submitted i.e it makes the queue wait". Based on that concept I created my own example which is as follows.The following snippet is written in the "viewDidLoad" method
dispatch_queue_t concQueue1 = dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);
void (^secondBlock)(void) =^( void)
{
//Second Block
for (int count=0; count<1000; count++)
{
if( [NSThread currentThread] == [NSThread mainThread ] )
{
NSLog(#"2 block main Thread") ;
}
else
{
NSLog(#"2 block other THREAD") ;
}
}
};
void (^firstBlock)(void) =^( void)
{
//First Block
for (int count=0; count<100; count++)
{
if( [NSThread currentThread] == [NSThread mainThread ] )
{
NSLog(#"1 block main Thread") ;
}
else
{
NSLog(#"1 block other THREAD") ;
}
}
dispatch_sync(concQueue1, secondBlock) ;
};
dispatch_async(concQueue1,firstBlock);
//Making the main thread sleep for some time
[NSThread sleepForTimeInterval:0.1] ;
dispatch_async( concQueue1, ^(void) {
//Third Block
for (int count=0; count<1000; count++)
{
if( [NSThread currentThread] == [NSThread mainThread ] )
{
NSLog(#"3 block main Thread") ;
}
else
{
NSLog(#"3 block other THREAD") ;
}
}
});
I am making the main thread sleep for some time so that dispatch_sync function in the "first block " gets executed. The output i am getting is this. I am showing the part of the output.
GCDExamples[2459:554259] 2 block other THREAD
.
.
.
GCDExamples[2459:554259] 2 block other THREAD
GCDExamples[2459:554256] 3 block other THREAD
GCDExamples[2459:554256] 3 block other THREAD
GCDExamples[2459:554259] 2 block other THREAD //Point first
GCDExamples[2459:554256] 3 block other THREAD
Some points about the output : The output shown in "3 block other THREAD" and "2 block other THREAD" are the first occurences of that output lines
MY QUESTION:
According to the concept because of dispatch_sync function once the second block starts it should make the queue wait rather than allowing "Third block" to start. But as shown in the earlier output "2 block other THREAD" follows "3 block other THREAD" statement at "//Point first" .This shows that the dispatch_sync function did'nt make the queue wait. How is that possible?? .Please ask me any another other infomration if needed.
EDIT 1 : I am putting the text of the well known book here to explain my point . The book is "iOS 7 Programming cookbook". Text follows:-
"For any task that doesn’t involve the UI, you can use global concurrent queues in GCD. These allow either synchronous or asynchronous execution. But synchronous execution does not mean your program waits for the code to finish before continuing. It simply means that the concurrent queue will wait until your task has finished before it continues to the next block of code on the queue. When you put a block object on a concurrent queue, your own program always continues right away without waiting for the queue to execute the code. This is because concurrent queues, as their name implies, run their code on threads other than the main thread."
As the bold text says that the concurrent queue would wait UNTIL my task is finished before continuing with the next block. My block printing "2 block other THREAD" should be allowed to finish before "3 block other THREAD" starts, but that is not the case my " 2 block other THREAD" is printed again intermingling with "3 block other THREAD" statement when in fact my all "2 block other THREAD" should be allowed to get completed and then "3 block other THREAD" should follow. Comment if more info is required.
"dispatch_sync function blocks the concurrent queue to which the block is submitted i.e it makes the queue wait"
If that's what the book says, throw it away. That's just wrong.
Synchronous vs. asynchronous is about the caller. When some code calls dispatch_sync(), that code can not proceed until the task being dispatched has completed. The queue is not blocked or forced to wait or anything like that.
By contrast, when code calls dispatch_async(), the task is put on the queue and the caller proceeds to its next step. It does not wait for the task that was dispatched to start, let alone finish.
That's a completely separate issue from whether a queue is concurrent or serial. That distinction belongs to the queues and the tasks they run, but doesn't directly affect the caller. A serial queue will only run one task at a time. If other tasks have been queued, they wait and run in strict sequence.
A concurrent queue can allow multiple tasks to run at the same time, depending on available system resources.
Update in response to edited question with new quote from the book:
For any task that doesn’t involve the UI, you can use global concurrent queues in GCD. These allow either synchronous or asynchronous execution. But synchronous execution does not mean your program waits for the code to finish before continuing. It simply means that the concurrent queue will wait until your task has finished before it continues to the next block of code on the queue. When you put a block object on a concurrent queue, your own program always continues right away without waiting for the queue to execute the code. This is because concurrent queues, as their name implies, run their code on threads other than the main thread.
This continues to be completely wrong. To take it part by part:
But synchronous execution does not mean your program waits for the code to finish before continuing.
That's exactly what "synchronous execution" does mean. When you submit a task synchronously, the submitting thread waits for the code to finish before continuing.
It simply means that the concurrent queue will wait until your task has finished before it continues to the next block of code on the queue.
No. The whole point of concurrent queues is that they don't wait for one task that is running before starting subsequent tasks. That's what "concurrent" means. A concurrent queue can run multiple tasks concurrently, at the same time, simultaneously.
When you put a block object on a concurrent queue, your own program always continues right away without waiting for the queue to execute the code.
No, this is wrong. It completely depends on what function you use to put that block on the queue. If it uses dispatch_sync(), it waits for the queue to execute the block. If it uses dispatch_async(), it does not wait; it continues right away. This is true whether the queue is serial or concurrent.
This is because concurrent queues, as their name implies, run their code on threads other than the main thread.
Any queue, serial or concurrent, other than the main queue, may run the blocks submitted to it on a background thread. And, if you use dispatch_sync() to submit a block to a concurrent queue from the main thread, it's very possible that the block will execute on the main thread. That's because GCD knows that the main thread isn't doing anything else, because it's blocked inside of the dispatch_sync() call, so it might as well run the block there.
In other words, the type of queue does not dictate which thread the block runs on.
The author of this book simply doesn't know what s/he is talking about.
First to understand, GCD you have to understand the difference between synchronous and asynchronous execution.
Synchronous = Executes as they are submitted and blocks the thread/queue they are submitted on.This means that:
The block (of code) only executes when it is it's turn in the queue.
The block (of code) will block the queue for executing and other blocks(of code & synchronous) will wait.
Basically the blocks will execute in a FIFO format.
Asynchronous = Starts executing immediately regardless of the queue/thread and does not block queue/thread.Executes even if something is executing on the queue(both synchronous and asynchronous).
To understand what when wrong, we will work through the code.
Lines 1-19 - Defined secondBlock
Lines 23-43 - Defined firstBlock
Line 47 - dispatch_async() firstBlock (Remember:Asynchronous execution)
Line 41[firstBlock] dispatch_sync() secondBlock (Remember: Synchronous execution)
Line 43[firstBlock] - firstBlock exits
Line 50 - Thread sleeps for 0.1 seconds
Line 52 - Define and Execute thirdBlock (Remember: Asynchronous execution).
The thirdBlock was executing asynchronously and started executing even if there is secondBlock executing on the queue.To achieve queuing of blocks(of code), us dispatch_sync().
Note
This functions operate relative to the concurrent queue.This means that dispatch_sync() will only be synchronous to the current queue. On other threads (such as the main thread) it appears to be asynchronous.
I have an app that uses a connection queue that handles the connections on a background thread. Each connection sends a JSON post, then when it receives a success, saves some objects into coredata.
Once all connections are complete, i call a dispatch_async on the main thread to call a finished method.
However, under very specific conditions of data im sending/saving, I've noticed the dispatch_async block to the main thread never gets called, and the app screen freezes, all execution stops, and the app sits idle with a frozen screen. processing power according to xcode is 0%.
Here is method with the block that fails.
- (void)connectionDidComplete
{
_completeConnections++;
_syncProgress = (float)_completeConnections / (float)_totalConnections;
dispatch_async(mainQueue, ^(void) {
[[NSNotificationCenter defaultCenter] postNotificationName:SyncQueueDidUpdateNotification object:nil];
}); <-- this dispatch works
if (_completeConnections == _totalConnections)
{
// clear unsynced data
NSArray *syncedObjects = [SyncObject completedSyncObjects];
if (syncedObjects.count > 0)
{
for (SyncObject *syncObject in syncedObjects)
{
[syncObject delete];
}
}
//this method saves the current context, then merges this context with the main context right after
[[VS_CoreDataManager sharedManager] saveManagedObjectContextAndWait:managedObjectContext];
// cleanup the thread's context
[[VS_CoreDataManager sharedManager] unRegisterManagedObjectContextForThread:currentThread];
managedObjectContext = nil;
// complete sync
dispatch_async(mainQueue, ^(void) {
[self performSelector:#selector(finishSync) withObject:nil afterDelay:2];
}); <-- this dispatch never gets called
}
}
My suspicion is this problem has something to do with saving the context then merging it. And possibly while that is happening its released in the middle of the merge, causing some weird hang up and the dispatch isn't getting executed. This is just a guess though, and I don't know how to fix it.
Any ideas?
Thanks.
If the block on the main thread is not executed, then it is because of 1 of 2 reasons.
The main thread is blocked; is not processing any events at all. Got a while() loop on the main thread? That'd do it. A lock? There you go.
The main thread is running a modal run loop inside the outer run loop. Asynchronous dispatches to the main event loop -- main thread -- won't be processed in this case.
Set a breakpoint on that dispatch_async() and see what the main thread is doing (at the point of dispatch the main thread is most likely already in the bad state).
DarkDust's suggestion of using dispatch_after() is a good one, but is unlikely to work in that it is almost assuredly the case that your main thread is not processing events when the problem occurs. I.e. fix the problem, then move to dispatch_after() as DarkDust suggests.
If your main thread is busy with modal runloop, then you could try
CFRunLoopPerformBlock(CFRunLoopGetMain(), kCFRunLoopCommonModes, block
});
I believe this is a great discussion. I came across this when I had the following code:
dispatch_synch(dispatch_get_main_queue()){
print("I am here")
}
the print code did not execute as I was dispatching a 'synch' block on the serial main thread which caused a dead lock. print was waiting for the dispatch to finish and dispatch was waiting for print to finish. When you dispatch in the main serial queue then you should use dispatch_async. and i guess if you use a concurrent queue then dispatch synch suits better
I have seen this code snippet:
dispatch_async(dispatch_get_main_queue(), ^{
[self doSomeNetworkStuff];
});
This doesn't look like making much sense to me.
EDIT: To clarify the conditions of my question:
The call to dispatch_async is performed from the main thread.
The sent message doSomeNetworkStuff is the heavy lifting worker task.
... and is not only the UI-updating task.
Dispatch, sure, but using the main queue would just pull the dispatched task back to the ui thread and block it.
Please, am I missing something?
Thanks.
dispatch_async lets your app run tasks on many queues, so you can increase performance.
But everything that interacts with the UI must be run on the main thread.
You can run other tasks that don't relate to the UI outside the main thread to increase performance.
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
//Add some method process in global queue - normal for data processing
dispatch_async(dispatch_get_main_queue(), ^(){
//Add method, task you want perform on mainQueue
//Control UIView, IBOutlet all here
});
//Add some method process in global queue - normal for data processing
});
Swift 3:
DispatchQueue.global(attributes: .qosBackground).async {
print("This is run on the background queue")
DispatchQueue.main.async {
print("This is run on the main queue, after the previous code in outer block")
}
}
when you want to do some Webservicecall or something you dispatch a async call like this below:
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT,0),^{
//Call your webservice here , your app will not freeze at all
});
Now, suppose you want to update or push a ViewController from your dispatched thread, if you directly push viewcontroller from this, app will or may get crashed,as such UI updates should be done in main thread of app,below is the answer for this then.
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT,0),^{
//Call your webservice here , your app will not freeze at all
//To update UIFrom dispatched Thread:
dispatch_async(dispatch_get_main_queue,^{
//Push view controller here
});
});
for detail visit : blackberrymastercracks.blogspot.in
It depends from where this code is being called. Means if its calling from main queue then it doesn't make sense. (Note: it will not cause a crash but it will just add a task in main queue ).
If this code is written in background thread then this is a converging point for the application. Like you are getting data from web service in background thread then wants to update it on UI then you can call it.
-(void) backgroundThreadFunction {
//Some stuff on background thread.
dispatch_async(dispatch_get_main_queue(), ^{
//Wants to update UI or perform any task on main thread.
[self doSomeNetworkStuff];
});
}
You can find more details over apple documentation https://developer.apple.com/library/ios/documentation/General/Conceptual/ConcurrencyProgrammingGuide/OperationQueues/OperationQueues.html
or from this answer also https://stackoverflow.com/a/19822753/505735
Do post me if its still unclear. I will write a detailed answer.
You'll usually see that syntax inside of another dispatch_async call that runs on a background thread. This is because all updates to the UI should happen on the main thread, not in the background.
I lost track of this question, but as it still gets traction, I'll post an answer to this (using swift)
Assumptions: I do know that UI work has to be done on the main thread.
//
// We are on the main thread here.
// The following will schedule the closure on the main thread after ALL other
// routines currently scheduled on the main thread are done.
//
DispatchQueue.main.async {
//
// So here we are back on the main thread AFTER all routines on the main
// thread have completed.
//
// If the following call does NOT dispatch onto a background thread
// it will block the UI and it was really bad programming.
//
// Thus, for now and for the benefit of the doubt, let's assume
// `doSomeNetworkStuff()` DOES dispatch to a background thread.
//
// This can only make sense if the the func `doSomeNetworkStuff()`
// relies on results of code paths following this current
// `DispatchQueue.main.async(... we are here ...)`.
//
// If `doSomeNetworkStuff()` does NOT depend on any other code paths:
// Why not directly scheduling it directly on a background thread?
// Which is unnecessary, as as stated above it MUST dispatch on to the
// background anyways.
//
// Moreover, there is few possibility that `doSomeNetworkStuff()` does
// depend on other codepaths, because `self` is already captured by
// the closure.
//
self.doSomeNetworkStuff()
}
Taking all this together IMHO the original code does not make very much sense. It could be replaced with:
// We are on the main thread here
self.doSomeNetworkStuff()
The original async dispatch onto the main thread to then dispatch to background should be wasteful and confusing (obviously).
Unfortunately I am not in the position anymore to try this out with the original code base.
Am I missing an idea here?