[mpiwg-hybridpm] Hybrid telecon fiasco

[Jim Dinan]

The concurrency and attribute semantics are in conflict with each other.
 Sure, attribute callbacks are problematic, but keep in mind that removing
the Comm_free concurrency exception results in an interface where you can
create endpoints, e.g. in MPI_THREAD_SERIALIZED mode, but you can't free
them.

The goal is to have two options for freeing endpoints communicators to
address these conflicting constraints.  MPI_Comm_free_endpoints would be
incompatible with collective attribute callbacks, but doesn't require
MPI_THREAD_MULTIPLE.  Comm_free is ok with collective attribute callbacks,
but requires MPI_THREAD_MULTIPLE.

Our thinking what that you should pass MPI_Comm_free_endpoints the array
that you got out of Comm_create_endpoints (maybe in a different order, but
all handles have to be there).  We were trying to keep the interface simple
for starters; we didn't intend for Comm_free_endpoints to mix with
Comm_free or do a subset free or anything else strange.  :)

 ~Jim.


On Mon, Apr 7, 2014 at 1:21 PM, Balaji, Pavan <balaji at anl.gov> wrote:

>
> On Apr 7, 2014, at 12:09 PM, Jim Dinan <james.dinan at gmail.com> wrote:
> > Dan suggested a third approach where we leave the Comm_free semantic
> unchanged and add a new function, MPI_Comm_free_endpoints(MPI_Comm
> comm_handles[], int my_num_ep), that has symmetry with
> Comm_create_endpoints.  An endpoints communicator can be freed with either
> Comm_free or Comm_free_endpoints.  They differ in their concurrency
> requirement.
>
> What happens to the attribute callbacks when you use
> MPI_Comm_free_endpoints?
>
>   -- Pavan
>
> _______________________________________________
> mpiwg-hybridpm mailing list
> mpiwg-hybridpm at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-hybridpm
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-hybridpm/attachments/20140407/b287d2f5/attachment-0001.html>