Question

I’m refactoring some time consuming function so that it can be called from a thread, but I’m having trouble wrapping my head around the issue (not very familiar with thread programming).

At any point, the user can cancel and the function will stop. I do not want to kill the thread as soon as the user cancels since it could cause some data integrity problems. Instead, in several places in the function, I will check if the function has been cancelled and, if so, exit. I will only do that where I know it’s safe to exit.

The whole code of the function will be within a mutex. This is the pseudo-code I have in mind:

SomeClass::SomeClass() {
    cancelled_ = false;
}

void SomeClass::cancelBigSearch() {
    cancelled_ = true;
}

void SomeClass::bigSearch() {
    mutex.lock();

    // ...
    // Some code
    // ...

    // Safe to exit at this point
    if (cancelled_) {
        mutex.unlock();
        cancelled_ = false;
        return;
    } 

    // ...
    // Some more code
    // ...

    if (cancelled_) {
        mutex.unlock();
        cancelled_ = false;
        return;
    }   

    // ...
    // Again more code
    // ...

    if (cancelled_) {
        mutex.unlock();
        cancelled_ = false;
        return;
    }   

    mutex.unlock();
}

So when the user starts a search, a new thread calls bigSearch(). If the user cancels, cancelBigSearch() is called and a cancelled_ flag is set. Then, when bigSearch() reaches a point where it’s safe to exit, it will exit.

Any idea if this is all thread-safe?

Answer 1

You should lock access to cancelled_ with another mutex, so checking and setting does not happen simultaneously. Other than that, I think your approach is OK

Update: Also, make sure no exceptions can be thrown from SomeClass::bigSearch(), otherwise the mutex might remain in a locked state. To make sure that all return paths unlock the mutex, you might want to surround the processing parts of the code with if (!cancelled_) and return only at the very end of the method (where you have the one unlock() call on the mutex.

Better yet, wrap the mutex in a RAII (acronym for Resource Allocation Is Initialization) object, so no matter how the function ends (exception or otherwise), the mutex is guaranteed to be unlocked.