使用Mutex挂起程序

Question

I am trying to learn concurrency programming in C++.

I implemented a basic stack class with push(), pop(), top() and empty() methods.

I created two threads and both of them will try to access the top element and pop it until the stack gets empty.

First, I tried to implement it without using a mutex, and the output was gibberish and in the end resulting in segfault , which was expected as the operations were not atomic so the data race was inevitable.

So I tried to implement it with a mutex, and the program was hanging without even giving any output because of not unlocking the mutex.

Now, I have used a mutex locking+unlocking sequence properly, my program is giving correct output as desired, But afterwards the program is hanging -- could be possibly due to threads are still in execution or control is not reaching to the main thread?.

#include <thread>
#include <mutex>
#include <string>
#include <iostream>
#include <vector>

using std::cin;
using std::cout;
std::mutex mtx;
std::mutex a_mtx;


class MyStack
{
    std::vector<int> stk;
public:
    void push(int val) {
        stk.push_back(val);
    }

    void pop() {
        mtx.lock();
        stk.pop_back();
        mtx.unlock();
    }

    int top() const {
        mtx.lock();
        return stk[stk.size() - 1];
    }

    bool empty() const {
        mtx.lock();
        return stk.size() == 0;
    }
};

void func(MyStack& ms, const std::string s)
{
    while(!ms.empty()) {
        mtx.unlock();
        a_mtx.lock();
        cout << s << " " << ms.top() << "\n";
        a_mtx.unlock();
        mtx.unlock();
        ms.pop();
    }

    //mtx.unlock();
}

int main(int argc, char const *argv[])
{
    MyStack ms;

    ms.push(3);
    ms.push(1);
    ms.push(4);
    ms.push(7);
    ms.push(6);
    ms.push(2);
    ms.push(8);

    std::string s1("from thread 1"), s2("from thread 2");
    std::thread t1(func, std::ref(ms), "from thread 1");
    std::thread t2(func, std::ref(ms), "from thread 2");

    t1.join();
    t2.join();

    cout << "Done\n";

    return 0;
}

I figured because once the stack was empty, I was not unlocking the mutex. So when I uncomment the commented line and run it, it gives gibberish output and segfault.

I don't know where I am doing a mistake. Is this the right way of writing a thread-safe stack class?

Answer 1

One error is that MyStack::top and MyStack::empty it does not unlock the mutex.

Use std::lock_guard<std::mutex> to unlock the mutex automatically and eliminate the risk of such accidental dead-locks. Eg:

bool empty() const {
    std::lock_guard<std::mutex> lock(mtx);
    return stk.empty();
}

And it probably needs to lock the mutex in MyStack::push as well.

---

Another error is that the locking at the method level is too fine grained and empty() followed by top() and pop() is not atomic.

Possible fixes:

class MyStack
{
    std::vector<int> stk;
public:
    void push(int val) {
        std::lock_guard<std::mutex> lock(mtx);
        stk.push_back(val);
    }

    bool try_pop(int* result) {
        bool popped;
        {
            std::lock_guard<std::mutex> lock(mtx);
            if((popped = !stk.empty())) {
                *result = stk.back();
                stk.pop_back();
            }
        }
        return popped;
    }
};

void func(MyStack& ms, const std::string& s)
{
    for(int top; ms.try_pop(&top);) {
        std::lock_guard<std::mutex> l(a_mtx);
        cout << s << " " << top << "\n";
    }
}

Answer 2

it gives gibberish output and segfault.

It will still potentially give you segfault under the current synchronization scheme, even if you go with the suggested RAII style locking like this:

void pop() {
    std::lock_guard<std::mutex> lock{ mtx };
    stk.pop_back();
}

int top() const {
    std::lock_guard<std::mutex> lock{ mtx };
    return stk[stk.size() - 1];
}

bool empty() const {
    std::lock_guard<std::mutex> lock{ mtx };
    return stk.size() == 0;
}

as you are not taking care of the race-condition arising between two subsequent calls to these methods by different threads. For example, think of what happens when the stack has one element left and one thread asks if it's empty and gets a false and then you have a context switch and the other thread gets the same false for the same question. So they're both racing for that top() and pop() . While the first one already pops it and then the other one tries to top() it will do so in a situation where stk.size() - 1 yields -1 . Hence, you get a segfault for trying to access a non-existing negative index of the stack : (

I don't know where I am doing a mistake. Is this the right way of writing a thread-safe stack class?

No, this is not the right way, the mutex only guarantees that other threads locking on the same mutex cannot be currently running this same section of the code. If they get to the same section, they're blocked from entering it until the mutex is released. But you are not locking at all between the call to empty() and the rest of the calls. One thread gets to empty() , locks, gets the value, then releases it, and then the other thread is free to enter and query and may well get the same value. What's preventing it later to enter your call to top() , and what's preventing the first thread to already be after that same pop() at that time?

In these scenarios you need to be careful to see the full scope of what needs protection in terms of synchronicity. The thing broken here is called atomicity , which means the property of "not being able be cut in middle". As you can see here it says that " Atomicity is often enforced by mutual exclusion, " -- as in by using mutexes, like you did. What was missing is that it was grained too finely -- the "size of the atomic" operation was too small. You should have been protecting the entire sequence of empty() - top() - pop() as a whole, as we now realize we cannot separate any piece out of the three. In code it could look something like calling this inside of func() and printing to cout only if it returned true :

bool safe_pop(int& value)
{
    std::lock_guard<std::mutex> lock{ mtx };

    if (stk.size() > 0)
    {
        value = stk[stk.size() - 1];
        stk.pop_back();
        return true;
    }

    return false;
}

Admittedly, this doesn't leave much for the parallel work here, but I guess it's a decent exercise in concurrency.