Global State Mutex vs Lock - c++

Question

This question isn't specific to glfw, but it serves well to describe what I mean. In glfw, in order to start using any functions we need to call glfwInit() and when we no longer need to use them we call glfwTerminate(), I've been trying to come up with a way to wrap this around a RAII class, and I've found two useful ways to do it, but I'm not sure of the pros and cons of each one. In all of these I'm omitting the error-checking and the such, as they won't change the examples too much.
1: Using a Lock-like class
My first idea was to have a lock-like class that called glfwInit() at the beginning of it's lifetime and glfwTerminate() and the end, something like this:
struct GLFWLock
{
GLFWLock() { glfwInit(); }
~GLFWLock() { glfwTerminate(); }
}
I realized that if two of these classes were created, then glfwInit and glfwTerminate would be called twice, so I added a ref counter and I felt like this was a fairly complete solution, aside from making it thread-safe and possible others, but it would essentially be the same thing:
struct GLFWLock
{
static size_t ref_count; /* = 0 in .cpp */
GLFWLock() { if ( ref_count == 0 ) { glfwInit(); } ref_count++; }
~GLFWLock() { ref_count--; if ( ref_count == 0 ) { glfwTerminate(); } }
}
2: Using a Mutex-like class
After working with the previous model for a bit, I realized it is the same as a std::lock_guard with a mutex, in a way, so I thought I could make a mutex class and have the user do a lock_guard whenever they needed to use glfw, instead of offering just a lock.
I ended up coming up with this, which somewhat fits the concept of mutex according to the standard, ignoring a few of the formal requirements and focusing on what std::lock_guard will actually use:
struct GLFWMutex
{
static size_t ref_count; /* = 0 in the .cpp */
bool locked = false;
~GLFWMutex() { unlock(); }
void lock()
{
if ( !locked )
{
if ( ref_count == 0 ) { glfwInit(); }
ref_count++;
locked = true;
}
}
void unlock()
{
if ( locked )
{
locked = false;
ref_count--;
if ( ref_count == 0 ) { glfwTerminate(); }
}
}
};
And then use it with std::lock_guard whenever it's needed, like a normal mutex.
I can see using the lock-like class is less that you have to type, since you don't have to declare a mutex and a guard, but would the mutex-like class be more useful? Possibly after adding more member functions like try_lock(), owns_lock() and others? Or is there a better solution to encapsulate this behavior?
Edit 1:
The usage syntax I'd like for this shared state would be something like:
struct glfw_shared_state
{
static size_t ref_count; /* = 0 in .cpp */
glfw_shared_state() { if ( ref_count == 0 ) { glfwInit(); } ref_count++; }
~glfw_shared_state() { ref_count--; if ( ref_count == 0 ) { glfwTerminate(); } }
};
struct Game
{
/// While this Game object is alive, I want to share the state of glfw, so it isn't terminated
glfw_shared_state state;
(...)
};
Where every instance of game would up the ref_count by one, which would make glfw stay alive throughout game's whole lifetime, basically a shared_ptr, but for functions instead of an object
Edit 2:
As for the std::lock_guard, what I meant was something like the following:
/// This has an internal ref counter for how many threads are currently locking it
/// When it first starts with 0 threads and someone locks, it calls glfwInit()
/// Then everytime some other thread locks, it just ups the ref counter
/// After every thread using it has unlocked it and it's ref counter is 0, it calls glfwTerminate()
/// So this isn't locking anyway, it's just sharing a state
glfw_mutex global_glfw_mutex;
void draw()
{
/// Make sure glfw is alive during this draw function
std::lock_guard lock(global_glfw_mutex);
}
It's a bit convoluted, but it's essentially what I meant with the second example in the original post, I think that mutex and lock aren't appropriate words for this, but I think the comment convey the meaning I want the code to have, the 'lock' is just a shared_ptr essentially