使用 std::try_to_lock 的意外行为

Question

I get surprising and conflicting behavior when I try to run the following code.

#include <iostream>
#include <mutex>

int main() {
    std::mutex mtx;
    std::unique_lock<std::mutex> lock1(mtx);
    std::unique_lock<std::mutex> lock2(mtx, std::try_to_lock);

    std::cout << "lock1 owns lock: " << lock1.owns_lock() << std::endl;
    std::cout << "lock2 owns lock: " << lock2.owns_lock() << std::endl;
}

When I run this on my computer (linux with either clang++ 4.0.1 or g++ 7.3.0) it prints out that both lock1 and lock2 own the lock (surprising). When I run this on cpp.sh it says that lock1 does own, but lock2 does not own the lock (what I expected).

All are using C++11 and -Wall without optimizations.

Answer 1

As stated in documentation for std::unique_lock constructor:

5. Tries to lock the associated mutex without blocking by calling m.try_lock(). The behavior is undefined if the current thread already owns the mutex except when the mutex is recursive.

Emphasis is mine. Since std::mutex is not recursive you have undefined behaviour - std::mutex::try_lock()

If try_lock is called by a thread that already owns the mutex, the behavior is undefined.

Answer 2

As was answered here, locking mutex that is already owned by the current thread is an undefined behavior according to the C++ standard, but it seems that you know that your implementation is based on POSIX Threads, which has a different set of requirements:

The pthread_mutex_trylock() function shall be equivalent to pthread_mutex_lock() , except that if the mutex object referenced by mutex is currently locked ( by any thread, including the current thread ), the call shall return immediately.

What you are observing is most likely caused by you not building your code using -pthread flag. GNU C++ library detects if program is linked against libpthread.so and if it is not, then all calls to lock / unlock functions are turned into no-op.

You can find some information here :

__gthread_mutex_lock is a one-line function that forwards to pthread_mutex_lock . Using GNU libc if you don't link to libpthread.so then pthread_mutex_lock is a no-op function that does nothing . It is quicker to just call it than to spend time checking if threads are active.

Or you can check the source code for std::mutex::lock in your header files yourself. You will see something like this:

void
lock()
{
  int __e = __gthread_mutex_lock(&_M_mutex);

  // EINVAL, EAGAIN, EBUSY, EINVAL, EDEADLK(may)
  if (__e)
     __throw_system_error(__e);
}

static inline int
__gthread_mutex_lock (__gthread_mutex_t *__mutex)
{
  if (__gthread_active_p ())
    return __gthrw_(pthread_mutex_lock) (__mutex);
  else
    return 0;
}

Function __gthread_active_p will return 0 if libpthread.so is not present in the current process, making mutex locking a no-op.

Adding -pthread will fix your problem, but you shouldn't rely on this - as demonstrated by your case.