Use gmx::Mutex and gmx::lock_guard to fix some issues
authorMark Abraham <mark.j.abraham@gmail.com>
Tue, 14 Feb 2017 23:37:33 +0000 (00:37 +0100)
committerMark Abraham <mark.j.abraham@gmail.com>
Fri, 17 Feb 2017 14:51:47 +0000 (15:51 +0100)
commitc70211cf2cb83682694c02c052d3b7a74833545a
treef89dc7a044b28d71b3a6ad41150388d431f71b9f
parent4be5e29d572e81ee5dc9f3697593112e66ec00f7
Use gmx::Mutex and gmx::lock_guard to fix some issues

Refactored a few uses of raw thread-MPI mutexes to fix known leaks, so
valgrind and LeakSanitizer become more useful.

Discovered that the thread-MPI trylock behaviour has always been buggy
on Windows, and cannot be fixed so that the return code is consistent
across the two current implementations in the case where the calling
thread might already own the lock. Fortunately, we don't use trylocks
anywhere, and the problematic case is unlikely to occur, but the
limitation is now documented.

Added unit tests for whichever mutex implementation we are using, now
and in the future. These cover the above case.

Found bugs in _where, which presumably wasn't an issue if it only
ran when handling errors. But it runs multiple times per MD step.

Refs #2122
Refs #2123

Change-Id: If1b2f092c569f47d67ce39e6decb56f04cea314a
cmake/legacy_and_external.supp
docs/doxygen/includesorter.py
src/external/thread_mpi/include/thread_mpi/mutex.h
src/external/thread_mpi/include/thread_mpi/threads.h
src/external/thread_mpi/src/pthreads.c
src/external/thread_mpi/src/winthreads.c
src/gromacs/fileio/gmxfio.cpp
src/gromacs/utility/fatalerror.cpp
src/gromacs/utility/futil.cpp
src/gromacs/utility/tests/CMakeLists.txt
src/gromacs/utility/tests/mutex.cpp [new file with mode: 0644]