Improve Communicator Design

[mschimek]

Checklist

• I have used the search function for open and closed issues to see if someone else has already submitted the same feature request.
• I will describe the problem with as much detail as possible.
• This request contains only one single feature, not a list of multiple (related) features. Please link related feature requests.

KaMPIng version

0.1.1

Problem you may be having, or feature you want

@niklas-uhl and I discussed the current kamping::Communicator design and concluded that ownership of the underlying MPI_Comm is not handled with sufficient care.

For example, the copy constructor of kamping::Communicator currently calls MPI_Comm_dup if the communicator is owning—a runtime property with currently somewhat ambiguous semantics that is both error-prone and a potential source of performance issues.

We believe that ownership of a kamping::Communicator should be a compile-time type property, allowing a clear distinction between an owning communicator and a communicator view.

This distinction would be particularly beneficial in more complex projects using kamping, where a communicator view could be used for example as a non-reference member in a class encapsulating distributed communication—avoiding unintended and costly duplications of the underlying communicator.

Suggested solution

Add a template non-type parameter to kamping::Communicator indicating whether it is owning or not.
When using a default for this template non-type parameter, this should be possible without breaking the current code.