Accéder au contenu.
Menu Sympa

starpu-devel - Re: [Starpu-devel] Heft/dmda: locking in compute_all_performance_predictions.

Objet : Developers list for StarPU

Archives de la liste

Re: [Starpu-devel] Heft/dmda: locking in compute_all_performance_predictions.


Chronologique Discussions 
  • From: Samuel Thibault <samuel.thibault@ens-lyon.org>
  • To: Cyril Roelandt <cyril.roelandt@inria.fr>
  • Cc: "starpu-devel@lists.gforge.inria.fr" <starpu-devel@lists.gforge.inria.fr>
  • Subject: Re: [Starpu-devel] Heft/dmda: locking in compute_all_performance_predictions.
  • Date: Thu, 22 Nov 2012 18:08:38 +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>

Cyril Roelandt, le Thu 22 Nov 2012 17:16:36 +0100, a écrit :
> if (exp_end[worker][nimpl] > max_exp_end)
> max_exp_end = exp_end[worker][nimpl];
> _STARPU_PTHREAD_MUTEX_UNLOCK(&sched_mutex[worker])
>
>
> The exact same code can be found in compute_all_performance_predictions() in
> dmda, except that we do not lock the worker's mutex. Why is that ?

I believe it's simply a bug. One should indeed take the lock, to make
sure to be getting a coherent set of {exp_start, exp_len} values. It
might be useful to only read those in the critical section, or even turn
the mutex into an rwlock.

Samuel





Archives gérées par MHonArc 2.6.19+.

Haut de le page