[mpiwg-p2p] Fwd: MPI P2P "messages may overtake" assertion

[Daniel Holmes]

Hi all,

Markus has reminded me that we discussed the effect of the 
mpi_assert_allow_overtaking assertion on tools (see below).

The basic problem is that message matching would be non-deterministic 
and it would be impossible for a tool to show the user which receive 
operation satisfied which send operation without internally using some 
sort of sequence number for each send/receive operation. As Markus 
mentions, this is a similar problem to the MPI_THREAD_MULTIPLE 
"logically concurrent" issue, with which tools already struggle.

My responses were:
1) the user asked for this behaviour so the tool could simply gracefully 
give up the linking function and just state the information it knows
2) the tool could hook all send and receive operations and piggy-back a 
sequence number into the message header
3) the tool could hook all send and receive operations and serialise 
them to prevent overtaking
I don't know the viability/acceptability of any of these approaches.

Preferably before the formal reading at the next face-to-face meeting, 
we should discuss the possibility that this assertion will disrupt tools 
and ascertain if we can/want to do anything to mitigate that disruption.

Cheers,
Dan.

-------- Forwarded Message --------
Subject: 	MPI P2P "messages may overtake" assertion
Date: 	Mon, 14 Dec 2015 16:24:44 +0100
From: 	Markus Geimer <m.geimer at fz-juelich.de>
To: 	dholmes at epcc.ed.ac.uk
CC: 	Marc-André Hermanns <m.a.hermanns at fz-juelich.de>



Hi Daniel,

Do you remember our conversation after the MPI BoF at SC'15 about the
proposed "messages may overtake" assertion and that it may cause severe
problems for tools, as correct message matching is very important for
many of them?  In fact, the issue here is similar to properly supporting
MPI_THREAD_MULTIPLE, which most tools don't do either right now...

Meanwhile I talked to Marc-Andre Hermanns from the Tools WG -- which
kick-started a discussion on this end.  But I guess this topic also
requires some involvement of the P2P WG.  For example, it would be good
if you could summarize the ideas you had in mind how tools could handle
this assertion. Thanks!

That said, I don't think there is any urgency for discussions, as
people are slowly leaving for the Christmas break (e.g., I'm already
out of office).  But we should definitely follow up on this early next
year.

Merry Christmas,
Markus

--
Dr. Markus Geimer
Juelich Supercomputing Centre
Institute for Advanced Simulation
Forschungszentrum Juelich GmbH
52425 Juelich, Germany

Phone:  +49-2461-61-1773
Fax:    +49-2461-61-6656
E-Mail: m.geimer at fz-juelich.de
WWW:    http://www.fz-juelich.de/jsc


------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------



-- 
Dan Holmes
Applications Consultant in HPC Research
EPCC, The University of Edinburgh
James Clerk Maxwell Building
The Kings Buildings
Peter Guthrie Tait Road
Edinburgh
EH9 3FD
T: +44(0)131 651 3465
E: dholmes at epcc.ed.ac.uk

*Please consider the environment before printing this email.*



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-p2p/attachments/20151214/4b6c4491/attachment.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: not available
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-p2p/attachments/20151214/4b6c4491/attachment.ksh>