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: Cyril Roelandt <cyril.roelandt@inria.fr>
  • To: Samuel Thibault <samuel.thibault@ens-lyon.org>, "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:26:15 +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>

On 11/22/2012 06:08 PM, Samuel Thibault wrote:
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.


OK. I'll keep using a mutex for now. While we are at it, do we really need to keep this:


if (exp_end[worker][nimpl]> max_exp_end)
max_exp_end = exp_end[worker][nimpl];

in the critical section ? max_exp_end is a local variable, and exp_end is a parameter of the function, I'm not sure they can be simultaneously modified by multiple threads.


Cyril Roelandt.





Archives gérées par MHonArc 2.6.19+.

Haut de le page