From patchwork Tue Jan 24 17:43:29 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Torvald Riegel X-Patchwork-Id: 137604 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 8AC43B6EE8 for ; Wed, 25 Jan 2012 04:43:51 +1100 (EST) Comment: DKIM? See http://www.dkim.org DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=gcc.gnu.org; s=default; x=1328031831; h=Comment: DomainKey-Signature:Received:Received:Received:Received:Received: Subject:From:To:Cc:Content-Type:Date:Message-ID:Mime-Version: Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:Sender:Delivered-To; bh=EBuUWUfyze2YVvnh47p6 rJlWkfU=; b=UNLN9PDeTfmU5rxmUOnSjAemGn+KzfMnb2Bv+jh/zcYtnG7q2ofA 1LDAXf0ZFzgvDZDUtmbuGoQ/e6wvW9BQ/G+xJnSz8wLVU5MCi7me2ewtBN7LtE0n 3Ys/65pPb/+t50rzp5L4e0XDHHKn+HoEbCOjVA/fNKwwX2iEmzyWIWY= Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gcc.gnu.org; h=Received:Received:X-SWARE-Spam-Status:X-Spam-Check-By:Received:Received:Received:Subject:From:To:Cc:Content-Type:Date:Message-ID:Mime-Version:X-IsSubscribed:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=XhVX85MERxJ62MWMLEQ/kgyUl8NOq5rd+SKoe0q3T9PW1NQcGg2uAi94x6C3Ph WW49LkrYYWwBTSUC2BpKIvq+xiX1DZVARUb5fX3fxbsfEi9lTsWmn5g7dSVZ0pA/ T7uziq2owwFI6RLaeo/TGaiQ8pWi2+qfZaPu40qf+M14I=; Received: (qmail 21570 invoked by alias); 24 Jan 2012 17:43:47 -0000 Received: (qmail 21554 invoked by uid 22791); 24 Jan 2012 17:43:46 -0000 X-SWARE-Spam-Status: No, hits=-6.7 required=5.0 tests=AWL, BAYES_00, RCVD_IN_DNSWL_HI, SPF_HELO_PASS, T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 24 Jan 2012 17:43:33 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q0OHhW5g031247 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 24 Jan 2012 12:43:32 -0500 Received: from [10.36.4.205] (vpn1-4-205.ams2.redhat.com [10.36.4.205]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q0OHhUxO014947; Tue, 24 Jan 2012 12:43:31 -0500 Subject: [patch] libitm: Fix wake-up of readers in futex-based serial lock. From: Torvald Riegel To: GCC Patches Cc: Richard Henderson , Aldy Hernandez Date: Tue, 24 Jan 2012 18:43:29 +0100 Message-ID: <1327427009.15992.684.camel@triegel.csb> Mime-Version: 1.0 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 This patch fixes a lost wake-up bug in the futex-based serial lock implementation. The previous code lacked some pieces of synchronization (a seq_cst barrier and resetting a flag that is checked by the respective futex_wait()), which led to those lost wake-ups when waking and waiting were racing against each other. Tested on ppc64 with microbenchmarks/STAMP and gl_wt. OK for trunk? commit a04fadca7c74f35d6d1d4f12d745c0ab44cc315a Author: Torvald Riegel Date: Tue Jan 24 15:05:42 2012 +0100 libitm: Fix wake-up of readers in futex-based serial lock. libitm/ * config/linux/rwlock.cc (GTM::gtm_rwlock::write_unlock): Fix reader wake-up. diff --git a/libitm/config/linux/rwlock.cc b/libitm/config/linux/rwlock.cc index 24e7042..ad1b042 100644 --- a/libitm/config/linux/rwlock.cc +++ b/libitm/config/linux/rwlock.cc @@ -231,10 +231,13 @@ gtm_rwlock::write_unlock () // last writer (this can happen because write_lock_generic() // exchanges 0 or 1 to 2 and thus might go to contended mode even if // no other thread holds the write lock currently). Therefore, we - // have to wake up readers here as well. - futex_wake(&readers, INT_MAX); + // have to wake up readers here as well. Execute a barrier after + // the previous relaxed reset of writers (Dekker-style), and fall + // through to the normal reader wake-up code. + atomic_thread_fence (memory_order_seq_cst); } - return; + else + return; } // No waiting writers, so wake up all waiting readers. // Because the fetch_and_sub is a full barrier already, we don't need