Assure, function runs under lock_guard

Question

I have a function foo() which is called from different places in a heavy multi-threaded environment.

It is modifying some sensitive data but due to the complexity I cannot use inside this function std::lock_guard... - this must be assured by the caller function. The reason is that the function is called several times in a row and the modified data [inside foo()] must not be touched in the meantime by other thread until the one thread finished all modifications by the several calls of foo().

We all are human - and especially me - and I was thinking about a way how to assure that the function foo() is indeed under the lock_guard... control and I just didn't forget to lock the scope.

For me - running under gcc and I don't have to consider any platform independent solution - I found this way:

auto foo( __attribute__ ((unused)) std::lock_guard<std::mutex> & guardActive ) -> void
{
   ...
}

Then, foo() must be called like this, otherwise already gcc does not compile it:

{
    std::lock_guard<std::mutex> lockScope( mutexObject );
    // block of commands calling foo() which must NOT be interrupted
    ...
    foo( lockScope );
    ...
    foo( lockScope );
    ...
    foo( lockScope );
    ...
}

My question:

Is this way OK, or are there better solutions? Reentrant mutex cannot be used.

Answer 1

I am convinced, the way I started was correct. I found this post On unnamed parameters to functions, C++ which more or less confirms me.

Now, I removed the parameter name and it is implemented like this:

auto foo( std::lock_guard<std::mutex> & ) -> void
{
   ...
}

which I find more elegant because it does not use the gcc extension and it is full C++ compatible.

Answer 2

The most comprehensive approach is to create a 'transaction object'. It's a variant of the 'Delegation Pattern' in which the transaction object coordinates access to an object. It can be thought of as lock_guard<> on speed. Like lock_guard<> it makes use of RAII to lock and then unlock the object allowing multiple actions to take place inbetween. Also like lock_guard<> optimization is likely to just unwrap all the inline calls and result in code exactly as performant as directly managing the mutex.

This example uses private to forbid access to the 'lock required' members outside a transaction.

In many cases this will surely be over-engineering particularly given a full implementation requires FooConstTrans and FooTrans classes depending on the const qualification of the referenced object.

#include <iostream>
#include <mutex>
#include <type_traits>

class FooTrans;

class Foo {
public:
    Foo():m_x(0)
    {}

friend class FooTrans;    
private:
    int get_x() const{
        return m_x;
    }

    void set_x(int x){
        m_x=x;
    }

    void lock() const{
        m_mutex.lock();
    }

    void unlock() const{
        m_mutex.unlock();
    }

private:
    mutable std::mutex m_mutex;
    int m_x;
};

class FooTrans final {
public: 
    FooTrans(Foo& foo):m_foo(foo){
        m_foo.lock();
    }

    void set_x(int x){
        m_foo.set_x(x);
    }

    int get_x(){
        return m_foo.get_x();
    }

    ~FooTrans(){
        m_foo.unlock();
    }


    private:
      Foo& m_foo;
};

int main() {

    Foo foo;
    FooTrans ft(foo);

    ft.set_x(3);
    //ft is guaranteeing the next line outputs '3' even if other threads are trying to access foo.
    std::cout << ft.get_x() <<std::endl;

    return 0;
}

Answer 3

If foo should always use the same mutex, for example if it's a member function and the class holds a mutex, I would go with this method:

void foo() {
    std::lock_guard<std::mutex> lock(someMutex);
    ...
}

Otherwise, it's often pushed to the caller of a method/class to moderate calling functions from different threads externally to the call using a lock like so:

{
    std::lock_guard<std::mutex> lock(someMutex);
    foo();
}

If you really think this is error prone (I don't) you could wrap it in a lambda as a convenience:

auto lockedFoo = [&]{ std::lock_guard<std::mutex> lock(someMutex); foo(); };