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

Reply via email to