C++ Threads, Std::System_Error - Operation Not Permitted

What causes runtime error message: std::system_error - operation not permitted, including mult-threading?

You are not linking pthread properly, try below command(note: order matters)

g++  main.cpp -o main.out -pthread -std=c++11

OR

Do it with two commands

g++ -c main.cpp -pthread -std=c++11         // generate target object file
g++ main.o -o main.out -pthread -std=c++11  // link to target binary

Threads 'std::system_error' what() Operation not permitted

std::system_error is thrown either by the std::thread constructor or by one of the unlocks.

Since you say that the program starts the threads properly, the latter is the problem. unlock throws std::system_error if there is no associated mutex or the mutex is not locked.

So in your case you are trying to unlock a mutex that is not locked, e.g. because you unlocked it before already.

Look at groceries_reception. If you take the first if (groceries_queue.empty()) branch you will unlock the mutex before the sleep. After the sleep you continue executing and the next if will be tested, which is if (!groceries_queue.empty()). Because other threads may have modified groceries_queue inbetween, now this branch may be taken as well. But in this branch you are calling locker.unlock() again. This is where the exception is thrown, because you are not actually holding the lock anymore.

The same problem is present in the other function. If you want to execute only one of the branches use else if.

However it would be much cleaner to let the lock unlock via its destructor at scope end. If you want to sleep after unlocking, simply make an artificial scope outside the lock's scope:

{
    unique_lock<mutex> locker(mutex1);
    // do something with lock, don't call unlock
}
std::this_thread::sleep_for(chrono::milliseconds(400));

or you can put the sleep before taking the lock if its fine to happen at the first loop iteration's beginning:

std::this_thread::sleep_for(chrono::milliseconds(400));
unique_lock<mutex> locker(mutex1);
// do something with lock, don't call unlock

g++ 4.8.1 C++ Threads, std::system_error - operation not permitted?

this was answered here

g++ -Wl,--no-as-needed -std=c++11 -pthread main.cpp -o main.out

Undeterministic std::system_error: what(): Operation not permitted

First you need to find out if the error is coming from your function that is being run by std::thread or from std::thread itself. If your function throws an exception it will be caught by the std::thread launcher function, and terminate will be called. If you make your function noexcept then terminate will get called before it's caught, and you'll see where it's thrown from in the stack trace (later versions of GCC don't catch the exception, so this happens automatically).

If the exception is coming from std::thread itself it means that your program has linked to the dummy definition of pthread_create in libc.so.6 instead of the real one in libpthread.so or libpthread.a

Use ldd to see if your program is linking to the shared libpthread.so or not. If it is, something's wrong with your toolchain (the definition in libpthread.so should get used instead of the weak symbol in libc.so). If you're linking statically, you might need to ensure that all symbols from libpthread.a are included in your program, e.g. by using:

-Wl,--whole-archive -pthread -Wl,--no-whole-archive

N.B. you should use -pthread not -lpthread as this allows GCC to ensure it is placed at the right place in the link command.

Why does std::condition_variable::wait_for() throw an operation not permitted std::system_error on Windows with VS2013?

Your program exhibits undefined behavior, by trying to unlock a mutex locked by a different thread. ourlock is originally constructed on the main thread, being a global variable, at which point it locks m. Then you pass it to cv.wait_for on the second thread. This is explicitly prohibited:

[thread.condition.condvar]

template <class Rep, class Period>
    cv_status wait_for(unique_lock<mutex>& lock,
                       const chrono::duration<Rep, Period>& rel_time);

25 Requires: lock.owns_lock() is true and lock.mutex() is locked by the calling thread...

Emphasis mine.

---

Related Topics