Something like a nested mutex but more generic? - c++

Question

I am working on a project where a file must be saved after some operations have been performed on a class's member objects. Sometimes we want to save the file after one operation, sometimes we need to not save it until after a batch of operations have been performed.
My idea is to use a class which basically works like a recursive mutex. Except instead of locking and unlocking a mutex, I want the class to call a method (in this case, save the file) when the last instance of the class in the stack falls out of scope.
Implementing a class which does this is not a problem, but this feels like a generic problem that I just can't find in Boost or STL. Is there a pre-existing standard solution to this problem, or do I need to roll my own class to do it? If so, is my approach the correct one, or is there a better way to solve the problem?
Below is a simple implementation of the kind of behavior I am looking for. It will only print "Hello World!" twice even though DoItOnce() is being called 11 times. I would like to use something like GenericGuard by pulling it from a recognized standard rather than sticking my own implementation in the code base. Is that possible?
#include <iostream>
void Noop (void) { }
void HelloWorld (void) { std::cout << "Hello World!" << std::endl; }
// This is what I imagine a generic implementation would look like...
template <void (*InitFunc)(), void (*DestructFunc)()>
class GenericGuard
{
int & _i;
public:
GenericGuard (int & i) : _i(i) { if (_i++ == 0) { InitFunc(); } }
~GenericGuard () { if (--_i == 0) { DestructFunc(); } }
};
int HelloWorldCounter; // Use a factory class in real-world?
typedef GenericGuard<Noop, HelloWorld> HelloWorldGuard;
void DoSomethingOnce (void)
{
HelloWorldGuard G (HelloWorldCounter);
// Do something
}
void DoItTenTimes (void)
{
HelloWorldGuard G (HelloWorldCounter);
for (int i = 0; i < 10; ++i)
{
DoSomethingOnce();
}
}
int main (void)
{
DoSomethingOnce();
DoItTenTimes();
return 0;
}

Answer 1

You can use a shared_ptr with a custom deleter function.
STL (since c++11): http://en.cppreference.com/w/cpp/memory/shared_ptr/shared_ptr
Boost: http://www.boost.org/doc/libs/1_55_0/libs/smart_ptr/shared_ptr.htm#deleter_constructor
Example :
#include <memory>
#include <iostream>
void HelloWorld(void *) { std::cout << "Hello World!" << std::endl; }
class factory
{
public:
static std::shared_ptr<void> get_instance()
{
static std::weak_ptr<void> ref;
if (ref.expired())
{
std::shared_ptr<void> sp{nullptr, HelloWorld};
ref = sp;
return sp;
}
return ref.lock();
}
};
void DoSomethingOnce (void)
{
std::shared_ptr<void> G = factory::get_instance();
// Do something
}
void DoItTenTimes (void)
{
std::shared_ptr<void> G = factory::get_instance();
for (int i = 0; i < 10; ++i)
{
DoSomethingOnce();
}
}
int main(void)
{
DoSomethingOnce();
DoItTenTimes();
return 0;
}

Answer 2

The pattern you're after seems to be wellknown indeed: you're looking to group operations in transactions[1].
Related patterns that come up in my mind are
Command pattern (with the famous Do/Undo example)
Composite pattern (so you can have a command that composes several other commands, forming a tree);
Unit Of Work pattern; this lets you group pending edits and apply them as a group
Software Transactional Memory (which focuses on real atomicity of operations, e.g. with exception safety).
No I'm not a stout advocate of patterns, but I like the concepts it gives you to talk about things: So, what you'd really want is Unit-Of-Work (which could be as simple as grouped Commands) and you want a "Transaction" that automatically applies the changes when destructed.
Depending on your actual application, it might be fine to stick with the mutable object approach that you appear to have now, and just serialize it occasionally. If the application domain becomes slightly more interesting (e.g. with threading, undo and or versioning?) you will quickly find that life gets a lot simpler when you move to a document model that is a graph of references to immutable nodes. This allows you to cheaply "edit" a complex object graph by simply replacing nodes. The nodes being immutable make it safe to share them, even in threaded environments.
I think related to your question is Sean Parent's Seasoning C++ talk. Although this focuses on how to organize your document model, I feel it might be pretty insightful and might give you the "breakthrough" change in point-of-view to make the problem simple again.
[1] which need not be atomic at all in this context, though they might (need to) be in your application domain.