16

I'm having a hard time figuring out how to put this all together. I have a puzzle solving app on the mac. You enter the puzzle, press a button, and while it's trying to find the number of solutions, min moves and such I would like to keep the UI updated. Then once it's finished calculating, re-enable the button and change the title.

Below is some sample code from the button selector, and the solving function: ( Please keep in mind I copy/paste from Xcode so there might be some missing {} or some other typos.. but it should give you an idea what I'm trying to do.

Basicly, user presses a button, that button is ENABLED=NO, Function called to calculate puzzle. While it's calculating, keep the UI Labels updated with moves/solution data. Then once it's finished calculating the puzzle, Button is ENABLED=YES;

Called when button is pressed:

- (void) solvePuzzle:(id)sender{
    solveButton.enabled = NO;
    solveButton.title = @"Working . . . .";

    // I've tried using this as a Background thread, but I can't get the code to waitTilDone before continuing and changing the button state.
    [self performSelectorInBackground:@selector(createTreeFromNode:) withObject:rootNode];

    // I've tried to use GCD but similar issue and can't get UI updated.
    //dispatch_queue_t queue = dispatch_queue_create("com.gamesbychris.createTree", 0);
    //dispatch_sync(queue, ^{[self createTreeFromNode:rootNode];});

    }

    // Need to wait here until createTreeFromNode is finished.
    solveButton.enabled=YES;
    if (numSolutions == 0) {
    solveButton.title = @"Not Solvable";
    } else {
        solveButton.title = @"Solve Puzzle";
    }
}

Needs to run in background so UI can be updated:

-(void)createTreeFromNode:(TreeNode *)node
{
   // Tried using GCD
   dispatch_queue_t main_queue = dispatch_get_main_queue();

 ...Create Tree Node and find Children Code...

if (!solutionFound){
    // Solution not found yet so check other children by recursion.
   [self createTreeFromNode:newChild];
   } else {
   // Solution found.
   numSolutions ++;
   if (maxMoves < newChild.numberOfMoves) {
       maxMoves = newChild.numberOfMoves;
    }
    if (minMoves < 1 || minMoves > newChild.numberOfMoves) {
        solutionNode = newChild;
        minMoves = newChild.numberOfMoves;

        // Update UI on main Thread

        dispatch_async(main_queue, ^{
                        minMovesLabel.stringValue = [NSString stringWithFormat:@"%d",minMoves];
                        numSolutionsLabel.stringValue = [NSString stringWithFormat:@"%d",numSolutions];
                        maxMovesLabel.stringValue = [NSString stringWithFormat:@"%d",maxMoves];
                    });
                }                        
bryanmac
  • 38,941
  • 11
  • 91
  • 99
Chris Young
  • 684
  • 2
  • 9
  • 23

3 Answers3

27

GCD and performSelectorInBackground samples below. But first, let's look at your code.

You cannot wait where you want to in the code above. Here's the code you had. Where you say wait in the comment is incorrect. See where I added NO.

- (void) solvePuzzle:(id)sender{
    solveButton.enabled = NO;
    solveButton.title = @"Working . . . .";

    // I've tried using this as a Background thread, but I can't get the code to waitTilDone before continuing and changing the button state.
    [self performSelectorInBackground:@selector(createTreeFromNode:) withObject:rootNode];

    // NO - do not wait or enable here.
    // Need to wait here until createTreeFromNode is finished.
    solveButton.enabled=YES;

}

A UI message loop is running on the main thread which keeps the UI running. solvePuzzle is getting called on the main thread so you can't wait - it will block the UI. It also can't set the button back to enabled - the work hasn't been done yet.

It is the worker function's job on the background thread to do the work and then when it's done to then update the UI. But you cannot update the UI from a background thread. If you're not using blocks and using performSelectInBackground, then when you're done, call performSelectorOnMainThread which calls a selector to update your UI.

performSelectorInBackground Sample:

In this snippet, I have a button which invokes the long running work, a status label, and I added a slider to show I can move the slider while the bg work is done.

// on click of button
- (IBAction)doWork:(id)sender
{
    [[self feedbackLabel] setText:@"Working ..."];
    [[self doWorkButton] setEnabled:NO];

    [self performSelectorInBackground:@selector(performLongRunningWork:) withObject:nil];
}

- (void)performLongRunningWork:(id)obj
{
    // simulate 5 seconds of work
    // I added a slider to the form - I can slide it back and forth during the 5 sec.
    sleep(5);
    [self performSelectorOnMainThread:@selector(workDone:) withObject:nil waitUntilDone:YES];
}

- (void)workDone:(id)obj
{
    [[self feedbackLabel] setText:@"Done ..."];
    [[self doWorkButton] setEnabled:YES];
}

GCD Sample:

// on click of button
- (IBAction)doWork:(id)sender
{
    [[self feedbackLabel] setText:@"Working ..."];
    [[self doWorkButton] setEnabled:NO];

    // async queue for bg work
    // main queue for updating ui on main thread
    dispatch_queue_t queue = dispatch_queue_create("com.sample", 0);
    dispatch_queue_t main = dispatch_get_main_queue();

    //  do the long running work in bg async queue
    // within that, call to update UI on main thread.
    dispatch_async(queue, 
                   ^{ 
                       [self performLongRunningWork]; 
                       dispatch_async(main, ^{ [self workDone]; });
                   });    
}

- (void)performLongRunningWork
{
    // simulate 5 seconds of work
    // I added a slider to the form - I can slide it back and forth during the 5 sec.
    sleep(5);
}

- (void)workDone
{
    [[self feedbackLabel] setText:@"Done ..."];
    [[self doWorkButton] setEnabled:YES];
}
bryanmac
  • 38,941
  • 11
  • 91
  • 99
  • 1
    Great explanation. But I have a question.. say my long running work, ( in this case would be your sleep statement ) needs recursion ? Can I recall performLongRunningWork again from inside itself without causing issues with the performSelectorOnMainThread workDone statement? wouldn't that end up calling work done as many times as the recursion is? I guess in this example, it's only setting the button properties but say workDone was doing more. – Chris Young Sep 03 '11 at 04:41
  • In the first sample with performSelectorInBackground you really couldn't because it calls to update UI within that function. You would have to track and condition that call out and condition in when recursion complete ... but ... – bryanmac Sep 03 '11 at 04:56
  • But, with the GCD sample, it's much cleaner - performWork can do whatever it wants. When it returns it will call workDone on main thread. – bryanmac Sep 03 '11 at 04:57
  • Yes thank you! I used the GCD example. Works great! Thank you so much.. I think I understand how to correctly use GCD and blocks now. Thank you so much. – Chris Young Sep 03 '11 at 07:22
  • Terrific answer, thanks bryan. I bountied! Related subtle question for anyone interested .. http://stackoverflow.com/q/25014581/294884 – Fattie Jul 29 '14 at 11:49
3
  dispatch_queue_t backgroundQueue;

  backgroundQueue = dispatch_queue_create("com.images.bgqueue", NULL);        


    - (void)process {    
    dispatch_async(backgroundQueue, ^(void){
    //background task
        [self processHtml];
    dispatch_async(main, ^{ 
// UI updates in main queue
   [self workDone]; 
    });

    });  
    });    
 }
user3279053
  • 187
  • 1
  • 10
0

By and large, any work to be submitted to a background queue needs to follow this pattern of code:

dispatch_queue_t queue = dispatch_queue_create("com.myappname", 0);

__weak MyClass  *weakSelf = self;  //must be weak to avoid retain cycle

//Assign async work
dispatch_async(queue, 
^{ 
   [weakSelf doWork]; 
   dispatch_async(dispatch_get_main_queue(), 
   ^{ 
      [weakSelf workDone]; 
    });
 }); 
 queue = nil;  //Using ARC, we nil out. Block always retains the queue.

Never Forget:

1 - queue variable above is a reference counted object, because it is a private queue, not a global one. So it is retained by the block which is executing inside that queue. Until this task is complete, it is not released.

2 - Every queue got its own stack which will be allocated / deallocated as part of recursive operation. You only need to worry about class member variables which are reference counted (strong, retain etc.) which are accessed as part of doWork above.

3 - While accessing those reference counted vars inside background queue operation, you need to make them thread-safe, depending on use cases in your app. Examples include writes to objects such as strings, arrays etc. Those writes should be encapsulated inside @synchronized keyword to ensure thread-safe access.

@synchronized ensures no another thread can get access to the resource it protects, during the time the block it encapsulates gets executed.

@synchronized(myMutableArray)
{
    //operation
}

In the above code block, no alterations are allowed to myMutableArray inside the @synchronized block by any other thread.

Nirav Bhatt
  • 6,940
  • 5
  • 45
  • 89
  • You are creating a serial queue, which ensures the order of task execution. This makes your @synchronized block superfluous. See the concurrency programming guide: https://developer.apple.com/library/ios/documentation/general/conceptual/concurrencyprogrammingguide/ThreadMigration/ThreadMigration.html#//apple_ref/doc/uid/TP40008091-CH105-SW3 – quellish Aug 04 '14 at 18:41
  • 1
    How about main queue competing with serial queue to modify something? Are serial queue guaranteed to finish before main queue takes over? – Nirav Bhatt Aug 04 '14 at 18:44
  • 1
    Hi @quellish, hmm I too do not follow you there, could you elaborate? Nirav is dispatching async (note the "a") right? – Fattie Aug 06 '14 at 07:49
  • 1
    @JoeBlow, he is enqueing the block for asynchronous execution on a serial queue, and providing an *additional* lock (@synchronized). Because it is a serial queue, the additional lock is unnecessary. See the concurrency programming guide section on writing lock-free code. Using a serial queue to protect access to the array replaces the lock. – quellish Aug 26 '14 at 21:42
  • Ahh - TBC, he's dispatching on to the queue "com.myappname", 0. that would be a serial queue, you're saying. So, now it makes sense! Thanks!! – Fattie Aug 27 '14 at 11:34
  • @quellish - this still does not address the case about main queue competing with serial queue. Can you quote relevant part from documentation to support your claim? – Nirav Bhatt Aug 27 '14 at 14:16