Smart pointers

[pazner]

There has been an ongoing discussion on further incorporating smart pointers (in particular, shared/reference-counted pointers) in MFEM. In order to be backwards compatible, it seems required to model "maybe owning" semantics — the smart pointer may own the pointed-to object, or it may not, and this depends on runtime information. Perhaps the simplest example is something like ProductOperator, whose declaration is given here:

mfem/linalg/operator.hpp

Lines 892 to 909 in 899a96b

	/// General product operator: x -> (A*B)(x) = A(B(x)).
	class ProductOperator : public Operator
	{
	const Operator *A, *B;
	bool ownA, ownB;
	mutable Vector z;
	public:
	ProductOperator(const Operator *A, const Operator *B, bool ownA, bool ownB);
	void Mult(const Vector &x, Vector &y) const override
	{ B->Mult(x, z); A->Mult(z, y); }
	void MultTranspose(const Vector &x, Vector &y) const override
	{ A->MultTranspose(x, z); B->MultTranspose(z, y); }
	virtual ~ProductOperator();
	};

Depending on the boolean flags ownA and ownB, the resulting ProductOperator may or may not own the pointed-to operators. The current implementation has incorrect copy/move semantics, which may cause issues in otherwise well-formed code (e.g. storing ProductOperator in a standard container), and the manual management of ownership rules may cause subtle bugs/memory leaks (see e.g. #4613 from as recently as today).

We can modify ProductOperator (and similar classes) in a fully backwards-compatible way using smart pointers that model "maybe owning" semantics. We have discussed two approaches to achieve this:

1. Using std::shared_ptr. An "owning" shared_ptr is created as usual, whereas a "non-owning" shared_ptr is created with a no-op deleter, e.g. [](T*){}. Convenience functions can be used to make specifying the ownership convenient and explicit.
   • Advantage: this uses standard classes and the implementation is correct. It is fully compatible with other code that uses shared_ptr.
   • Disadvantage: the non-owning version is a somewhat non-standard use of shared_ptr (it was referred to in the meeting as an "abuse") and it may confuse users. We can't provide our own documentation for this class. An existing shared_ptr can't be easily queried about whether it is owning or not.
2. Using a custom type (e.g. Handle<T>) that is built on top of shared_ptr.
   • Advantage: we can fully document the semantics of this type, users won't be surprised by "non-owning" pointers, we can add functions to query whether it is owning or not, and we can potentially add extra functionality if needed to be applicable to more classes in MFEM.
   • Disadvantage: a custom type will not be familiar to users, and careful implementation will be required to avoid bugs.

[v-dobrev]

Note that the no-op deleter can be the same for all types T -- the argument can be just void* -- the only requirement for the deleter is that the expression deleter(p) makes sense when p is T*.

[termi-official]

In order to be backwards compatible, it seems required to model "maybe owning" semantics — the smart pointer may own the pointed-to object, or it may not, and this depends on runtime information.

Maybe a wild take on this, but don't you think it is worth breaking backwards compat in turn to simplify lifetime management? This should be done with a clear upgrade path described for users which want to go forward. From my understanding the "maybe owning" semantics stems from the issue that the objects are not reference counted in MFEM, hence it is not a-priori clear which object has to live for how long a priori. Hence there are flags introduced to manage this lifetime information manually. Keeping the product operator you have at top as an example, with shared pointer this problem would not occur, as the pointer itself manages its lifetime (by reference counting).

Furthermore, for non-owning semantics we have https://en.cppreference.com/w/cpp/memory/weak_ptr

[v-dobrev]

I don't think breaking backward compatibility is a good idea without some transition period for users. That's why we want to figure out what the "new" interface will look like while preserving the "old" one, at least for some time.

Regarding the use of weak_ptr: weak_ptr always needs a shared_ptr that owns the pointer, however, we often have just a raw pointer which we cannot simply store in a weak_ptr.

[rcarson3]

@v-dobrev for you what would be an acceptable time frame / versions be to transition from the old version to a new breaking change version? Since, I definitely understand where you're coming from as I'm currently doing something similar with a library I maintain with a few hundred users. I've got a planned 2 major version transition to go from the old -> old w/new -> only new to make sure my users code doesn't break in weird ways with major changes.

I will also say I'm also for whatever the eventual transition is as I've also been bitten by who owns what interfacing with a number of different aspects of the MFEM library and the various raw ptrs being passed around.

[v-dobrev]

@rcarson3, depending on how often you have major releases, 2 major releases seems reasonable to me, as long as that gives users at least 6 months to plan and do the transition. If the library is relatively big and the changes affect a lot of functions/methods, one should probably allow more time, e.g. at least 12 months. That said, I think, MFEM has a lot of deprecated methods that have not been removed for a long time (years). 😄