Accéder au contenu.
Menu Sympa

starpu-devel - Re: [Starpu-devel] Is StarPU busy-waiting for tasks ?

Objet : Developers list for StarPU

Archives de la liste

Re: [Starpu-devel] Is StarPU busy-waiting for tasks ?


Chronologique Discussions 
  • From: Samuel Thibault <samuel.thibault@ens-lyon.org>
  • To: Benoît Lizé <benoit.lize@gmail.com>
  • Cc: starpu-devel@lists.gforge.inria.fr
  • Subject: Re: [Starpu-devel] Is StarPU busy-waiting for tasks ?
  • Date: Tue, 5 Nov 2013 14:37:47 +0100
  • 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>

Hello,

Benoît Lizé, le Wed 30 Oct 2013 12:27:25 +0100, a écrit :
> It looks like the worker will spin, if _starpu_machine_is_running() doesn't
> block.

Yes, that's it. You can also make the pop operation block by passing
--enable-blocking-drivers to ./configure. That is however a bit more
expensive and it not tested as much.

> Would it be possible to add something like:
> starpu_pause();
>
> that would make _starpu_machine_is_running() block until a symmetric call
> such
> as
> starpu_resume()
> is called ?
>
> I'm no expert in threading, but wouldn't a condition variable fulfill this
> role
> ?
>
> void starpu_pause() {
>   starpu_task_wait_for_all();
>   // set the condition variable to "wait"
> }
>
> void starpu_resume() {
>   // signal the end of the waiting period.
> }

That could be an idea, yes, the only thing is that we really want the
test in machine_is_running to be scalable, so the condition variable
should be first quickly checked without locking (which scales well since
all processors will have their own copy), before locking again to wait
properly.

Samuel





Archives gérées par MHonArc 2.6.19+.

Haut de le page