CODEWITHSUNDEEP
multithreadingc++11
Pui Ho Lam
Pui Ho Lam

Reputation: 230

mutex destroyed while busy

There is a singleton object of EventHandler class to receive events from the mainthread. It registers the input to a vector and creates a thread that runs a lambda function that waits for some time before deleting the input from the vector to prevent repeated execution of the event for this input for some time.

But I'm getting mutex destroyed while busy error. I'm not sure where it happened and how it happened. I am not even sure what it meant either because it shouldn't be de-constructed ever as a singleton object. Some help would be appreciated.

class EventHandler{
public:
    std::mutex simpleLock;
    std::vector<UInt32> stuff;
    void RegisterBlock(UInt32 input){
        stuff.push_back(input);
        std::thread removalCallBack([&](UInt32 input){
            std::this_thread::sleep_for(std::chrono::milliseconds(200));
            simpleLock.lock();
            auto it = Find(stuff, input);
            if (it != stuff.end())
                stuff.erase(it);
            simpleLock.simpleLock.unlock();
        }, input)
        removalCallBack.detach();
    }
    virtual EventResult ReceiveEvent(UInt32 input){
            simpleLock.lock();
            if (Find(stuff, input) != stuff.end()){
                RegisterBlock(input));
                //dostuff
            }
            simpleLock.simpleLock.unlock();
    }
};

Upvotes: 2

Views: 13045

Answers (1)

waTeim
waTeim

Reputation: 9235

What is happening is that a thread is created

std::thread removalCallBack([&](UInt32 input){
   std::this_thread::sleep_for(std::chrono::milliseconds(200));
   simpleLock.lock();
   ...
removalCallBack.detach();

And then since removalCallBack is a local variable to the function RegisterBlock, when the function exits, the destructor for removalCallBack gets called which invokes std::terminate()

Documentation for thread destructor

~thread(); (since C++11)

Destroys the thread object. If *this still has an associated running thread (i.e. joinable() == true), std::terminate() is called.

but depending on timing, simpleLock is still owned by the thread (is busy) when the thread exits which according to the spec leads to undefined behavior, in your case the destroyed while busy error.

To avoid this error, you should either allow the thread to exist after the function exits (e.g. not make it a local variable) or block until the thread exits before the function exits using thread::join

Dealing with cleaning up after threads can be tricky especially if they are essentially used as different programs occupying the same address space, and in those cases many times a manager thread just like you thought of is created whose only job is to reclaim thread related resources. Your situation is a little easier because of the simplicity of the work done in the thread created by removalCallBack, but there still is cleanup to do.

If the thread object is going to be created by new, then although system resources used by the system thread the C++ thread object represents will get cleaned up, but the memory the object uses will remain allocated until delete is called.

Also, consider if the program exits while there are threads running, then the threads will be terminated, but if there is a mutex locked when that happens, once again there will be undefined behavior.

What is usually done to guarantee that a thread is no longer running is to join with it, but though this doesn't say, the pthread_join man page states

Once a thread has been detached, it can't be joined with pthread_join(3) or be made joinable again.

Upvotes: 7

Related Questions