An idea for the GSL to make multithreading code safer.

I have what I think maybe (or may not be lol) a potential candidate for the GSL.

The basic idea is very simple. There are just a few wrapper classes used to enforce read/write locking and, at the same time, presenting either a const (for read-only) or non-const (for read-write) view of the wrapped object.

The idea is to make it compile-time impossible to improperly access a resource shared between threads.

The read-only version (readable_lock) contains an internal shared_lock and binds a const reference (const&) to the target object ensuring that only const functions can be invoked.

The read_write version (writable_lock) contains an internal unique_lock and a non-const reference (&) to the target allowing updates to its internal state.

Here is some example usage:

lockable<std::vector<int>> v;          // lockable vector wrapper

v.push_back(3);                        // compile error

std::cout << v.size() << '\n';         // compile error

// locks are released at the end of their scope
{
	auto ro_v = v.lock_for_reading();  // read-only locked wrapper

	ro_v->push_back(3);                // compile error

	std::cout << ro_v->size() << '\n'; // OK! (const functions accessible)
}

{
	auto rw_v = v.lock_for_writing();  // read-or-write locked wrapper
	
	rw_v->push_back(3);                // OK! (non const functions accessible)
	
	std::cout << rw_v->size() << '\n'; // OK! (const functions accessible)
}

lockable<std::size_t> i{0};            // lockable integer wrapper

{
	auto [ro_v, rw_i] = lock(for_reading(v), for_writing(i));   // deadlock safe locking
	
	ro_v->push_back(*rw_i);            // compile error (ro_v is read only)
	
	*rw_i = ro_v->size();              // OK!
}

Does this sound like a useful addition to the library?

To be honest I am not even sure of the practicality as I have not used this technique in an actual project. But on paper, to me at least, it looks like it could be quite useful.

I have a preliminary working version for the above code. However my template meta-programming skills are not the best so it is possible/likely I have missed a lot of tricks and gotchas. Also, there are some crucial features yet to be implemented (like copy/move semantics).