From patchwork Wed Dec 23 16:29:45 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Florian Weimer X-Patchwork-Id: 560609 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]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id C1816140C05 for ; Thu, 24 Dec 2015 03:29:58 +1100 (AEDT) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.b=qhKoop0b; dkim-atps=neutral DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:subject:to:references:cc:from:message-id:date :mime-version:in-reply-to:content-type; q=dns; s=default; b=bnrE OY1uSig6/ehX5del2v5jQH2vJnHvwxUxRItJc5ib8JWryYZA5aFNusdyMwmay39E /F8Pc/D6//h28VHOGIAhwIN1l5mQ7Q/hpwOWipC4Q9KMJAja7YOEGyE2Xcz2t9Ho xtya7CgYIRbBQk25vngTri+esuWxRGoEEjdlcS4= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:subject:to:references:cc:from:message-id:date :mime-version:in-reply-to:content-type; s=default; bh=xt2bcTKadg soH5By/uxcAeHJc/0=; b=qhKoop0biuYw/8/69fB/asheoCdeTcWfF8Px8ip2rQ QlZUknEP/MUmj7TH8CxzZWas4adnIqJxe9jJ1X/S75Wk7813JGnfBhlF+suTRXk8 otdGEl746p2Hk0kzbY+lQGehwnLJAy1wobyLKcHHtA5E6+ltcNNEyxnmG512/YgY 0= Received: (qmail 70027 invoked by alias); 23 Dec 2015 16:29:50 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Delivered-To: mailing list libc-alpha@sourceware.org Received: (qmail 70018 invoked by uid 89); 23 Dec 2015 16:29:49 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.5 required=5.0 tests=AWL, BAYES_20, LIKELY_SPAM_BODY, RP_MATCHES_RCVD, SPF_HELO_PASS autolearn=no version=3.3.2 spammy=seo, suffers, eduardo, Eduardo X-HELO: mx1.redhat.com Subject: [PATCH COMMITTED] malloc: Update comment for list_lock To: "Carlos O'Donell" , Torvald Riegel References: <56389C10.6060001@redhat.com> <56642691.7060806@redhat.com> <1449852593.27311.98.camel@localhost.localdomain> <566F1114.1060706@redhat.com> <1450380373.26597.29.camel@localhost.localdomain> <56740C24.90901@redhat.com> <5678751E.1030605@redhat.com> <5679A559.6010703@redhat.com> <5679AF92.9080406@redhat.com> Cc: GNU C Library From: Florian Weimer Message-ID: <567ACBF9.2050302@redhat.com> Date: Wed, 23 Dec 2015 17:29:45 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <5679AF92.9080406@redhat.com> On 12/22/2015 09:16 PM, Carlos O'Donell wrote: > On 12/22/2015 02:32 PM, Florian Weimer wrote: >> On 12/21/2015 10:54 PM, Carlos O'Donell wrote: >> >>>> + list_lock also prevents concurrent forks. When list_lock is >>>> + acquired, no arena lock must be acquired, but it is permitted to >>>> + acquire arena locks after list_lock. */ >>> >>> This last sentence seems ambiguous to me. I assume you mean to say that >>> at the point at which list_lock is acquired there are no other arena >>> locks held, but that after list_lock is acquired, other arena locks may >>> be acquired afterwards? >> >> That was my intent. Is this clearer? >> >> list_lock also prevents concurrent forks. At the time list_lock is >> acquired, no arena lock must have been acquired, but it is permitted >> to acquire arena locks subsequently, while list_lock is acquired. >> >> I'm following Torvald's earlier guidance not to speak of “held” locks. > > Looks good to me. Thanks, committed. Florian From 7962541a32eff5597bc4207e781cfac8d1bb0d87 Mon Sep 17 00:00:00 2001 Message-Id: <7962541a32eff5597bc4207e781cfac8d1bb0d87.1450888146.git.fweimer@redhat.com> From: Florian Weimer Date: Wed, 23 Dec 2015 17:23:33 +0100 Subject: [PATCH] malloc: Update comment for list_lock To: libc-alpha@sourceware.org --- ChangeLog | 4 ++++ malloc/arena.c | 7 ++++--- 2 files changed, 8 insertions(+), 3 deletions(-) diff --git a/ChangeLog b/ChangeLog index a32717e..9063848 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,7 @@ +2015-12-23 Florian Weimer + + * malloc/arena.c (list_lock): Update comment. + 2015-12-22 Carlos Eduardo Seo * sysdeps/powerpc/hwcapinfo.c: Export symbol diff --git a/malloc/arena.c b/malloc/arena.c index 85f1194..665be5e 100644 --- a/malloc/arena.c +++ b/malloc/arena.c @@ -85,9 +85,10 @@ static mstate free_list; _int_new_arena. This suffers from data races; see the FIXME comments in _int_new_arena and reused_arena. - list_lock also prevents concurrent forks. When list_lock is - acquired, no arena lock must be acquired, but it is permitted to - acquire arena locks after list_lock. */ + list_lock also prevents concurrent forks. At the time list_lock is + acquired, no arena lock must have been acquired, but it is + permitted to acquire arena locks subsequently, while list_lock is + acquired. */ static mutex_t list_lock = _LIBC_LOCK_INITIALIZER; /* Mapped memory in non-main arenas (reliable only for NO_THREADS). */ -- 2.4.3