Notes 2017 03 16

Participants

• Marc-Andre Hermanns
• Jeff Squyres
• Woo-Sun Yang
• Soren Rassmussen

Notes

• Sources as a virtual construct to create chronological event streams
  • The MPI_T_EVENT_SOURCE_BEST_EFFORT does not make much sense
    • No difference for implementors, as almost the same checks apply
    • Tool still needs to handle similar to the UNORDERED case
  • Still currently the only concepts to allow prior buffer allocation for the tools (cannot allocate buffers in callbacks)
  • Maybe easier to explain as with an analogy:
    • A source is like a communicator
    • Events from a single source are ordered just like messages between the same source/destination on a communicator.
    • Events from different sources are allowed to be triggered without chronological order, just like messages on different communicators may overtake each other
  • Default should be MPI_T_EVENT_SOURCE_ORDERED
    • MPI_T_EVENT_SOURCE_UNORDERED only for sources that for some reason cannot be guaranteed to be in order
  • Maybe Dan's proposal to use sequence IDs may enable tools to re-create order or use a sliding-window approach
    • Not all sources will be able to implement such a sequence number
    • Don't we have the same problems when trying to generate a unique sequence ID (i.e., a logical timestamp)
• Open Questions
  • What about dynamic source lists?
    • Can a new event source appear dynamically by loading a specific module?
  • What about events comming from tasks?
    • Might migrate across threads