Block switching thread in iOS - ios

Question

I have troubles with multiple threads. Here is the situation:
I make asynchronous requests to backend and, in some cases, need to cancel these. Canceling the requests happens in a separate thread. All requests to the backend are canceled and, as I exit a screen, multiple class instances are deallocated.
When I have the order request-cancel, everything works fine. However, sometimes the cancel method is invoked when I am already in the middle of the finish method (which needs a little bit time because of decoding and conversion of data). In such cases, the app crashes, a messages to deallocated instance is sent. It is not an exception that can be easily cached, I get the crash even when I check for the existence of the instances a line before. Actually, if I understand it right, the instance of the class where the finish and the cancel method are located, is deallocated. Nevermind, the problem is that the thread is switched in the middle of the finish method and I need to prevent that.
My question is: Is there a way to block switching the thread in the middle of a method? To declare this method as a whole (transaction)? Or is there another standard solution for such a problem?
I read this post but I don't really understand whether it can be used in my case or how to do that.
EDIT: Canceling
for (XXX *request in [XXX sharedQueue].operations)
{
[request setDelegate:nil];
[request setDownloadProgressDelegate:nil];
[request setUploadProgressDelegate:nil];
[request setQueue:nil];
[request cancel];
}
XXX is the class used for the requests.
Order of the methods
Here is the order in which the methods are invoked (in the cases of error). Handler is the class for handling the requests.
Handler 1: make request
Handler 1: finish begin
Handler 2: cancel begin
Handler 2: cancel end
Handler 2: dealloc
Handler 1: dealloc
Handler 1: finish middle
Handler 1 and 2 are two instances of the class. The first one is deallocated in the middle of the finish method, so at the end of this I get a crash. Deallocating it is normal because after cancel I go to another view and basically everything gets deallocated.
My ideas for solution are either to somehow prevent going back to the finish method or to execute the entire finish method before switching the thread. Unfortunately, I have no idea how one of these could be implemented.

Answer 1

The following approach might help you:
add a flag to your controller managing all requests;
when a request finish block is entered do like this:
completionBlock:^() {
#synchronized(self.myFinishFlag) {
...
}
}
in your cancel method do like this:
-(void)userCancelledRequests:(id)sender {
#synchronized(self.myFinishFlag) {
...
}
}
This will delay the execution of 'userCancelledRequestsbody if a finish block is currently running (i.e., lockingself.myFinishFlag`).
Hope this helps.

Answer 2

It appears that the cancel method of class XXX is not correctly implemented.
Suppose there is some asynchronous operation of type XXX which responds to a cancel message. In order to function reliable, the following requirements must be fulfilled:
The cancel message can be send from a client from any thread.
The cancel message can be send at any time and multiple times.
When the operation receives the cancel message, it stops it asynchronous task and cleans up itself properly at the next "cancelation point". Note: this may happen asynchronously with respect to the cancel method. The implementation needs to be "thread safe"!
The receiver shall notify the delegate that it has been cancelled (for example in a failure handler).
Furthermore, there should be no need for a caller to reset the delegate(s) or prepare the receiver in any way before sending the cancel message.
These requirements needs to be fulfilled by the implementation of class XXX.
Now, suppose you have an internal finish method for that operation and lets suppose that this is the last method which will be executed by the operation. When that method is executed, and when the operation receives a cancel message concurrently, the implementation must guarantee that the cancel has no effect, since it is too late: the last opportunity to cancel the operation has been passed. There are a number of ways how to accomplish this.
If this is true, then the following code should properly cancel your operations:
for (XXX *request in [XXX sharedQueue].operations) {
[request cancel];
}
Edit:
Example for an "NSOperation like" implementation of a cancel and finish method:
Note:
Accessing ivars must be synchronized! Ivars will be accessed in various internal methods. All accesses will be serialized via a private serial dispatch queue, named "sync_queue".
- (void) cancel {
dispatch_async(self.sync_queue, ^{
if (_isCancelled || _isFinished) {
return;
}
[self.task cancel]; // will sets _isCancelled to YES
[self finish]; // will set _isFinished to YES
});
}
- (void) finish
{
assert(<execution context equals sync_queue>);
if (_isFinished)
return;
completionHandler_t onCompletion = self.completionHandler;
if (onCompletion) {
id result = self.result;
dispatch_async(dispatch_get_global_queue(0, 0), ^{
onCompletion(result);
});
};
self.completionHandler = nil;
self.task = nil;
self.isExecuting = NO;
self.isFinished = YES;
}

Answer 3

The best way to block is to perform all operations on a dedicated queue. When you want to cancel, do it like this:
dispatch_async(_someQueue, ^{
for (XXX *request in [XXX sharedQueue].operations)
{
[request setDelegate:nil];
[request setDownloadProgressDelegate:nil];
[request setUploadProgressDelegate:nil];
[request setQueue:nil];
[request cancel];
}
});
Then when the finished callback is triggered, you can do this:
dispatch_async(_someQueue, ^{
if ([request isCancelled] == NO)
{
// Process request
}
});
So long as _someQueue is not marked as a concurrent queue, this should do the trick.