From patchwork Thu Dec 1 11:28:08 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Alan Modra X-Patchwork-Id: 128683 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) by ozlabs.org (Postfix) with SMTP id CAA9CB6F18 for ; Thu, 1 Dec 2011 22:28:34 +1100 (EST) Received: (qmail 6163 invoked by alias); 1 Dec 2011 11:28:32 -0000 Received: (qmail 6135 invoked by uid 22791); 1 Dec 2011 11:28:31 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=AWL, BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-yx0-f175.google.com (HELO mail-yx0-f175.google.com) (209.85.213.175) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 01 Dec 2011 11:28:16 +0000 Received: by yenr11 with SMTP id r11so1755005yen.20 for ; Thu, 01 Dec 2011 03:28:15 -0800 (PST) Received: by 10.236.181.234 with SMTP id l70mr10481212yhm.49.1322738895840; Thu, 01 Dec 2011 03:28:15 -0800 (PST) Received: from bubble.grove.modra.org ([115.187.252.19]) by mx.google.com with ESMTPS id r4sm14493525anl.5.2011.12.01.03.28.13 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 01 Dec 2011 03:28:15 -0800 (PST) Received: by bubble.grove.modra.org (Postfix, from userid 1000) id EC87A170C2BF; Thu, 1 Dec 2011 21:58:08 +1030 (CST) Date: Thu, 1 Dec 2011 21:58:08 +1030 From: Alan Modra To: gcc-patches@gcc.gnu.org Cc: Richard Henderson , Jakub Jelinek Subject: PR libgomp/51376 fix Message-ID: <20111201112808.GH28621@bubble.grove.modra.org> Mail-Followup-To: gcc-patches@gcc.gnu.org, Richard Henderson , Jakub Jelinek MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org The simple one-line fix in GOMP_taskwait took many hours to find. Shared memory problems are a pain to debug, especially when adding code to dump some state turns a testcase that fails every hundred or so runs into one that takes thousands of times longer to fail. What happens here is that GOMP_taskwait is called in the parent thread some time after gomp_barrier_handle_tasks has run in the child to the point of clearing the parent's "children" field. However, since there is no acquire barrier in the parent and the child may or may not have reached the release barrier in the mutex unlock, the memory stores in the child are not guaranteed to be seen in order in the parent thread. Thus the parent can see "task->children" clear but not yet see stores done as part of the real work of the child, ie. to "a" and "n" in the testcase. 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. Index: libgomp/task.c =================================================================== --- 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) {