Header-only library for multithreaded programming

#include "libguarded/guarded.hpp"

struct Foo
{
    int value;
};

int main()
{
    libguarded::guarded<Foo> m_foo;
    auto lock = m_foo.lock();
    return 0;
}

1>c:\program files (x86)\microsoft visual studio 12.0\vc\include\memory(1377): error C2280: 'std::unique_lock<M>::unique_lock(const std::unique_lock<M> &)' : attempting to reference a deleted function
1>          with
1>          [
1>              M=std::mutex
1>          ]
1>          c:\program files (x86)\microsoft visual studio 12.0\vc\include\mutex(285) : see declaration of 'std::unique_lock<M>::unique_lock'
1>          with
1>          [
1>              M=std::mutex
1>          ]
1>          This diagnostic occurred in the compiler generated function 'libguarded::guarded<Foo,std::mutex>::deleter::deleter(const libguarded::guarded<Foo,std::mutex>::deleter &)'

I ran into a situation where I needed to be able to unlock a shared_guarded object for a short time while a callback was called.

the callback could in principle call other functions that would trigger the same lock, so I couldn't have the lock be engaged while the callback was executing.

But this was executing in a loop so the lock needed to reengaged after the callback finished.
an unlock() function on the handle would be really nice but that would require the handle be a full class instead of a unique_ptr, so I settled for setting the handle to nullptr then calling lock again.

This generated a compile error as the use of M & m_deleter_mutex; is not move assignable, thus the deleter class itself is not move_assignable and the handle is not move_assignable, and there was no way to have a lock reassigned to an existing variable.

My solution was to change the deleter class to store M * instead of M & and change the unlock call to use -> instead of . and the constructor to store &mutex instead. This allowed the handle to be move_assignable and at least some work around to temporary unlocking.

The same issue would be true for guarded and ordered_guarded and probably others as well. this the cost of course is that now deleter has a pointer instead of a reference and could not be zero size, but there had to be some mechanism for temporary disengaging the lock otherwise the guarded classes are unusable for a number of purposes.

There are a variety of other alternatives, but the issue is that there is no means of temporarily suspending a lock in a conditional branch.

After getting the question: so what is libguarded useful for, reading the github description it looks like a wrapper for std::mutex, but I dont get the point. I thought I would take a stab at a more to the point description. I hope you like it :)

compile-tested only, but submitting for early review

adds an allocate_unique() with associated deleter for use when exception safety is needed adds a separate m_zombie_alloc for zombie list nodes implements rcu_list(const Alloc &alloc) constructor

The implementation of this method is missing! https://github.com/copperspice/cs_libguarded/blob/f16f2da5934adfe22a04c68340e49ecc7d3fd1f0/src/cs_rcu_list.h#L101

The file has a HAVE_CXX14 define required - can this be updated otherwise I get incomplete type warnings.

I ended up just editing the file and changing the #if to #ifndef

Current cmake file indicates 1.2.0 but there is only one tag on this repository which is nearly 4 years old: 1.1.0 Do you expect to release a new version of libguarded at some point ?

TL;DR:

Please revert https://github.com/copperspice/cs_libguarded/commit/98b9c17e76b9dc639f2936146e2201f52c5b2f44

Discussion

IIRC there were really good reasons to have C++ header files end with .hpp rather than .h. Some had to do with IDE discriminating between C and C++. I believe the Boost Community went through this discussion some decades ago, but I can't find the original discussion quickly. Please find other opinions below

Pro

• https://stackoverflow.com/questions/152555/h-or-hpp-for-your-class-definitions
• https://www.boost.org/users/faq.html

  Why do Boost headers have a .hpp suffix rather than .h or none at all? File extensions communicate the "type" of the file, both to humans and to computer programs. The '.h' extension is used for C header files, and therefore communicates the wrong thing about C++ header files. Using no extension communicates nothing and forces inspection of file contents to determine type. Using '.hpp' unambiguously identifies it as C++ header file, and works well in actual practice. (Rainer Deyke)

• https://llvm.org/docs/CodingStandards.html#file-headers

Contra

• Bjarne is against my proposal :frowning_face:
• Google Coding Guidelines

Compared to other C++ libraries like e.g. range-v3 this repository does not follow the best practice to avoid name clashes by putting headers into a directory that corresponds to the library name. So it is not possible to write

#include <cs_libguarded/some_header.hpp>

I propose to change the directory structure and CMake files such that there is a directory structure similar to

├── include
│   └── cs_libguarded
│       ├── header_1.hpp
│       ├── header_2.hpp
│       ├── ...
│       └── header_N.hpp
├── README.md
├── src
│   ├── maybe_implementation_for_header_1.cpp
│   └── etc.cpp
└── test
    ├── CMakeLists.txt
    ├── test_1.cpp
    ├── test_main.cpp
    └── test_N.cpp

Great library and fantastic work! Here is a small change to reduce lines of code using decltype(auto) if you are interested. I only tested it on Linux (arch) but am sure it will work on any C++14 compliant compiler :crossed_fingers: .

Hello,

I'm trying to install the library on Linux. The compilation runs fine, but when I try to install it ('sudo make install'), installation fails with the message:

Install the project...
-- Install configuration: ""
CMake Error at cmake_install.cmake:41 (file):
  file INSTALL cannot find
  "/home/user/Downloads/sources/cs_libguarded/src/test_cow.hpp": No such
  file or directory.

Am I doing something wrong?

• Unnecessary Lock type parameter removed from shared_guarded. For the shared use-case at the moment I do not see any other valid option than the shared_lock.

• Unnecessary lock check removed in the handler deleter: null unique_ptr does not call the deleter (https://en.cppreference.com/w/cpp/memory/unique_ptr/%7Eunique_ptr), so the conditional statement there is always true.

• Simplified the invalid handle related code: with default constructible unique_ptr deleter, the invalid handle is easier (and maybe cheaper) to generate