Accéder au contenu.
Menu Sympa

starpu-devel - Re: [Starpu-devel] Why starpu_mpi_barrier waits for all taks ?

Objet : Developers list for StarPU

Archives de la liste

Re: [Starpu-devel] Why starpu_mpi_barrier waits for all taks ?


Chronologique Discussions 
  • From: Samuel Thibault <samuel.thibault@inria.fr>
  • To: Philippe SWARTVAGHER <philippe.swartvagher@inria.fr>
  • Cc: starpu-devel@lists.gforge.inria.fr
  • Subject: Re: [Starpu-devel] Why starpu_mpi_barrier waits for all taks ?
  • Date: Tue, 14 Apr 2020 18:23:52 +0200
  • List-archive: <http://lists.gforge.inria.fr/pipermail/starpu-devel/>
  • List-id: "Developers list. For discussion of new features, code changes, etc." <starpu-devel.lists.gforge.inria.fr>
  • Organization: I am not organized

Philippe SWARTVAGHER, le mar. 14 avril 2020 18:02:00 +0200, a ecrit:
> Why starpu_mpi_barrier waits for all tasks ?

In the way we were using it (a synchronization in the task graph), it
has to be so, because MPI requests can make tasks ready, which can make
MPI requests ready, etc. So for starpu_mpi_wait_for_all, we need that
behavior.

> Could we consider creating a function starpu_mpi_barrier_unsafe(), calling
> directly MPI_Barrier ?

Actually starpu_mpi_barrier itself could have that behavior, just like
starpu_mpi_send/recv() don't care much about the task graph of the STF
flow. But we need our current implementation for
starpu_mpi_wait_for_all.

Put another way, I'd say:

- rename _starpu_mpi_barrier to _starpu_mpi_wait_for_all
- call _starpu_mpi_wait_for_all from starpu_mpi_wait_for_all
- create a new _starpu_mpi_barrier which works like you said.

Samuel




Archives gérées par MHonArc 2.6.19+.

Haut de le page