From patchwork Wed May 3 19:25:25 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Carlos O'Donell X-Patchwork-Id: 20238 Received: (qmail 9209 invoked by alias); 3 May 2017 19:25:29 -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 9194 invoked by uid 89); 3 May 2017 19:25:28 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-27.1 required=5.0 tests=BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, RCVD_IN_DNSWL_LOW, RCVD_IN_SORBS_SPAM autolearn=ham version=3.3.2 spammy=behaviours, states X-HELO: mail-qt0-f182.google.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=nhkP7M3OqB04Meqtvf/3XkziwN7AICPhZ8ujN156mXQ=; b=RvsGsnVFkemXtD9VPNoAOczdMcEnwiAJ0tGzI1L+14dMU54l6f46/qcHSlgBz0tS4f W/jK7xwyudSeSE1t5knSTxA4K14fKMdx3yDIqgv+3wjA8gnSoH+PBKzv73ZRfvPD4Sc8 F2UCUGZHn/AhGijRY5T+tq5hRE/e7D4e7rIDLb89Z8dSfIU/WFxQNwMuA1oHNX5Etcjs nWRIoE2cf12qEee+boTzel8Ke7OnnB2Gl8lE/Dd03G1MAwVoFNr0S690OOf5gjIbBMca BagwOhm2udeAwZ1zr+YRlgw5D3zNl9ejWcQvcgEyqyxkB5xCQmcHxSr4tcOmH4igUOM7 F5bw== X-Gm-Message-State: AN3rC/7T6s9zDQWPRf6qgAxJ6q89DM/zt1gsJxJRNHHZfXTMdiLpauFr 9Fi9uYqkGTRl7RxQ X-Received: by 10.200.48.149 with SMTP id v21mr9722188qta.84.1493839528371; Wed, 03 May 2017 12:25:28 -0700 (PDT) Subject: Re: [PATCH] Bug #20116: Clarify barrier-like and mutex-like behaviours of PD->lock. To: Torvald Riegel , Florian Weimer Cc: GNU C Library References: <3d358d5a-66eb-cf97-ad98-16061a838f1a@redhat.com> <116d8b2d-dad1-c5f6-8cf7-59e0c969381d@redhat.com> <7299daa1-f56f-ecca-5e04-76279b9afde1@redhat.com> <31ac5901-dec8-da57-72bc-91854d2c656e@redhat.com> <1489494370.26906.260.camel@redhat.com> From: Carlos O'Donell Message-ID: <8e5068f5-eb94-bd96-2521-6e88fd37c3a3@redhat.com> Date: Wed, 3 May 2017 15:25:25 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.0 MIME-Version: 1.0 In-Reply-To: <1489494370.26906.260.camel@redhat.com> On 03/14/2017 08:26 AM, Torvald Riegel wrote: > It's not a barrier actually, but closer to a semaphore (the parent does > not wait for the child to arrive, but continues immediately after > posting...). I integrated Torvald's comments and this is what I checked in. I believe this suffices to clarify the concurrency notes for the case Florian wanted clarified. 2017-05-03 Carlos O'Donell [BZ #20116] * nptl/pthrad_create.c: Expand comments to describe semaphore-like and mutex-like uses of PD->lock. diff --git a/nptl/pthread_create.c b/nptl/pthread_create.c index d0d7414..c7d1b8f 100644 --- a/nptl/pthread_create.c +++ b/nptl/pthread_create.c @@ -94,8 +94,17 @@ unsigned int __nptl_nthreads = 1; exactly which of the four ownership states we are in and therefore what actions can be taken. For example after (2) we cannot read or write from PD anymore since the thread may no longer exist and the - memory may be unmapped. The most complicated cases happen during - thread startup: + memory may be unmapped. + + It is important to point out that PD->lock is being used both + similar to a one-shot semaphore and subsequently as a mutex. The + lock is taken in the parent to force the child to wait, and then the + child releases the lock. However, this semaphore-like effect is used + only for synchronizing the parent and child. After startup the lock + is used like a mutex to create a critical section during which a + single owner modifies the thread parameters. + + The most complicated cases happen during thread startup: (a) If the created thread is in a detached (PTHREAD_CREATE_DETACHED), or joinable (default PTHREAD_CREATE_JOINABLE) state and