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
- [Starpu-devel] Heft/dmda: locking in compute_all_performance_predictions., Cyril Roelandt, 22/11/2012
- Re: [Starpu-devel] Heft/dmda: locking in compute_all_performance_predictions., Samuel Thibault, 22/11/2012
- Re: [Starpu-devel] Heft/dmda: locking in compute_all_performance_predictions., Cyril Roelandt, 22/11/2012
- Re: [Starpu-devel] Heft/dmda: locking in compute_all_performance_predictions., Samuel Thibault, 23/11/2012
- Re: [Starpu-devel] Heft/dmda: locking in compute_all_performance_predictions., Cyril Roelandt, 22/11/2012
- Re: [Starpu-devel] Heft/dmda: locking in compute_all_performance_predictions., Samuel Thibault, 22/11/2012
Archives gérées par MHonArc 2.6.19+.