Objet : Developers list for StarPU
Archives de la liste
- From: Samuel Thibault <samuel.thibault@ens-lyon.org>
- To: Nathalie Furmento <nathalie.furmento@labri.fr>
- Cc: "starpu-devel@lists.gforge.inria.fr" <starpu-devel@lists.gforge.inria.fr>
- Subject: Re: [Starpu-devel] Freebsd and pthread_barrier_wait
- Date: Wed, 17 Jul 2013 10:05:04 +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>
Nathalie Furmento, le Tue 16 Jul 2013 17:07:02 +0200, a écrit :
> As valgrind indicates below, one of the workers belonging to the parallel
> job ends (even though there is a barrier) and destroys the job structure,
> while the other worker is stil waiting on the barrier.
That can happen if the pthread_barrier implementation does not wait for
completion of threads that have just finished the barrier. It seems this
has been fixed in FreeBSD on March 16 2012:
http://gitorious.org/freebsd/freebsd/commit/d9571701029083f16d4fe87e0cdb7f0694a6169a
I have checked POSIX, it says only “The results are undefined if
pthread_barrier_destroy() is called when any thread is blocked on the
barrier”. Here the thread is not blocked, it has just been unblocked.
So according to POSIX I believe it really was a FreeBSD bug (and trying
to circumvent it would be messy).
Samuel
- [Starpu-devel] Freebsd and pthread_barrier_wait, Nathalie Furmento, 16/07/2013
- Re: [Starpu-devel] Freebsd and pthread_barrier_wait, Samuel Thibault, 17/07/2013
Archives gérées par MHonArc 2.6.19+.