From patchwork Mon Feb 13 13:29:41 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: 19240 Received: (qmail 71839 invoked by alias); 13 Feb 2017 13:29:47 -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 71828 invoked by uid 89); 13 Feb 2017 13:29:46 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL, BAYES_00, RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM autolearn=no version=3.3.2 spammy=948, rightly, states X-HELO: mail-qk0-f181.google.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:organization:message-id:date :user-agent:mime-version:content-transfer-encoding; bh=VLAeqjMyWT5XPocinOCKVNTOX0pNg5AqGwhc5nMyEvM=; b=RGE60/oFeOUC/peGNLe+MYvAxS5esR0mZGCSzA3or7AlU6peB4CFLNQBvRzevjj4SN WERHHD7YExezV0Jcpc5VvKRd2aD0NwDgEcEHDMXNrEnnf1fMcEVoXFFRweQTHm9WFbEo kAQl+Z1vVCSkSSM/VPmXqlkn2FUAfqRIQpJAq/FK4RZqjN0eXRXO/1UsX3VVA6EG5KOQ kl9ouPg0h++SsNxwpewWifprDyQoUv6hY5NYoz1EjybI3psoitWH3rl03Llf+WGycHSt FlMi2QQS/r1mbPUYMpcUid2iFQLnM1L+hLz6/GpoLx7WlKw529A7fDTCAilVXsTxX+qw iagg== X-Gm-Message-State: AMke39lQPHy0Ek3O6I9KWwNYF8/qEVTVW/BwMXTXDKDwrDF6JE3fB9wVi5yw6CTqpKH+zLAp X-Received: by 10.55.11.130 with SMTP id 124mr20672405qkl.27.1486992584109; Mon, 13 Feb 2017 05:29:44 -0800 (PST) To: GNU C Library , Florian Weimer From: Carlos O'Donell Subject: [PATCH] Bug #20116: Clarify barrier-like and mutex-like behaviours of PD->lock. Message-ID: <3d358d5a-66eb-cf97-ad98-16061a838f1a@redhat.com> Date: Mon, 13 Feb 2017 08:29:41 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 Florian Weimer rightly pointed out to me that we use PD->lock in two distinct ways, at startup in a barrier-like fashion, and later in a mutex-like fashion. This should be clarified in the concurrency notes because it implies two different algorithms are at play using the same concurrency structure. Also note that a normal POSIX lock would not be valid to use in this case because it is not valid for another thread to unlock it (the barrier-like use-case at startup). OK to commit? 2017-02-13 Carlos O'Donell [BZ #20116] * nptl/pthrad_create.c: Expand comments to describe barrier-like and mutex-like uses of PD->lock. diff --git a/nptl/pthread_create.c b/nptl/pthread_create.c index 2ef2bcb..b522638 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 as a POSIX + barrier and a POSIX mutex. The lock is taken in the parent to force + the child to wait, and then the child releases the lock, in effect a + barrier. However, this barrier-like effect is used only for + synchronizing the parent and child. After startup the lock is used + like a mutex to create a critical region 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