Documentation of communication preconditions

[fabian-jung]

The way graybat works, it assumes that some preconditions are met to achive higher speedup. Since this preconditions are not checked by the compiler, they should be well documented.

Here is a list, of all preconditions, that come to my mind:

To send data:

• it must be linear in memory (that one is subject to change at the moment)
• it must not contain pointer or references, since they may be invalid after receive (subject to change see #123 )

To receive data:

• the container must be big enought to receive all data (subject to change)

For heterogenious systems (different compiler and/or different architecture)

• the layout of the data has to be the same on all paticipants
  • this is the result of the memcpy operations
  • using fixed width types
  • may be enforced by restricting padding for complex types
• all paticipants interpret the binary data in the same way
  • little/big endian convertion is up to the user

I think there are some more with respect to the availability of copy/move and default constructors. There may be some more, which i did not figured out yet.

[erikzenker]

Currently, I am trying to document the send and recv data properties through concept like documentation in #118. Furthermore, there is ongoing work to remove some of the mentioned conditions above.

I did not yet think about systems with different endians or varying word sizes, because I had the assumption that the underlying communication library or at least the communication policy should care.

Actually, each used template should be completely specified.

[erikzenker]

I added comments in "concept like" syntax is a first step to better documentation in #129. Is this something that could help you? Where can I improve further?

[fabian-jung]

This is a big help. The small downside is, that until it is integrated into the compiler one has to check all functions in graybat to check for the requisites.