Why mutex has been unlocked - c++

Question

I have this code:
mainwindow.h:
namespace Ui {
class MainWindow;
}
class MainWindow : public QMainWindow {
private:
QMutex mutex;
}
mainwindow.cpp:
void MainWindow::on_calculateBtn_clicked() {
QMutexLocker locker(&mutex);
qDebug() << "mutex has been locked" << endl;
ui->calculateBtn->setEnabled(false);
startProcess(); // huge calcutations
ui->calculateBtn->setEnabled(true); // performed before startProcess() has finished (why?)
qDebug() << "mutex will be unlocked" << endl;
}
If I click calculateBtn again while startProcess() has not finished, my program crashed:
pure virtual method called
The program has unexpectedly finished.
I tried:
void MainWindow::on_calculateBtn_clicked() {
if (!processing) {
processing = true;
ui->calculateBtn->setEnabled(false);
startProcess();
ui->calculateBtn->setEnabled(true); // performed before startProcess() has finished (why?)
processing = false;
}
}
There is no shared data, I just want one startProcess() will not be started before other startProcess() finished.
Why did it happen? I think that mutex have to lock function startProcess() in on_calculateBtn_clicked() and nothing should happens. It seems I don't know any important things. Thanks in advance for any advice.

Answer 1

The same mutex is locked twice from the same thread (the main thread, which contains the event loop), which is invalid for a non-recursive mutex.
But even a recursive mutex will not solve the basic problem of your code; you need a flag to indicate that you are already doing the calculations, and return from all subsequent calls to your method while they are running, else you'll start them multiple times in the same thread, one interrupting the other, probably with bad results. Even better, disable the button while the method is running and take care it isn't called by other ways.
However, if calling startProcess() multiple times and run it simultaneously is intended, you'll have to start a thread for each button press and take care for access to shared data (using mutexes, most probably) - that's where the real fun begins.

Answer 2

I think that you (by default) have a Qt::DirectConnection with this button press, right? i.e.:
connect(..., SIGNAL(...),
..., SLOT(:on_calculateBtn_clicked()), <by-default-Qt::DirectConnection>);
The issue I see here is that the first button press will run the function void MainWindow::on_calculateBtn_clicked() immediately.... which is all good so far, the mutex is locked and huge calcs are running.
However when you press the button again, void MainWindow::on_calculateBtn_clicked() is again immediate run (like an interrupt). The first thing it does is try to lock the mutex and it must hang here.
If you make connection to the slot void MainWindow::on_calculateBtn_clicked() Qt::QueuedConnection then it won't trigger the button press until it has clear the other tasks on its task queue.
but.... weather or not your design here is good is questionable, I think over you should re-think your strategy (as some comments have suggested)
EDIT
Oh yeah, meant to add..... to answer your question, therefore I don't think the mutex is begin unlocked twice... its just the nature of the direct connection