This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: PR libgomp/51376 fix
- From: Jakub Jelinek <jakub at redhat dot com>
- To: gcc-patches at gcc dot gnu dot org, Richard Henderson <rth at redhat dot com>
- Date: Thu, 1 Dec 2011 12:36:08 +0100
- Subject: Re: PR libgomp/51376 fix
- References: <20111201112808.GH28621@bubble.grove.modra.org>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Thu, Dec 01, 2011 at 09:58:08PM +1030, Alan Modra wrote:
> The GOMP_task change fixes a similar potential problem. Bootstrapped
> and regression tested powerpc-linux. OK to apply?
>
> PR libgomp/51376
> * task.c (GOMP_taskwait): Don't access task->children outside of
> task_lock mutex region.
> (GOMP_task): Likewise.
Can't this be solved just by adding a barrier? The access to the var
outside of the lock has been quite intentional, to avoid locking in the
common case where there are no children.
> --- libgomp/task.c (revision 181833)
> +++ libgomp/task.c (working copy)
> @@ -116,12 +116,12 @@ GOMP_task (void (*fn) (void *), void *da
> }
> else
> fn (data);
> - if (task.children)
> - {
> - gomp_mutex_lock (&team->task_lock);
> - gomp_clear_parent (task.children);
> - gomp_mutex_unlock (&team->task_lock);
> - }
> + if (team != NULL)
> + gomp_mutex_lock (&team->task_lock);
> + if (task.children != NULL)
> + gomp_clear_parent (task.children);
> + if (team != NULL)
> + gomp_mutex_unlock (&team->task_lock);
> gomp_end_task ();
> }
> else
> @@ -290,8 +290,9 @@ GOMP_taskwait (void)
> struct gomp_task *child_task = NULL;
> struct gomp_task *to_free = NULL;
>
> - if (task == NULL || task->children == NULL)
> + if (task == NULL)
> return;
> +
> gomp_mutex_lock (&team->task_lock);
> while (1)
> {
Jakub