From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-Status: No, score=-4.2 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id D75461F55B for ; Wed, 3 Jun 2020 17:52:13 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id DF6C3388C001; Wed, 3 Jun 2020 17:52:12 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org DF6C3388C001 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1591206732; bh=t1PRLtMyKYF+0avmN8bIyIwujoUeD3MKlf+TttUCwPE=; h=To:References:Subject:Date:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=vru8vFa4g8nOzuDJYsbAJ+/HFSjzXfT0JJ+oyheq56uYky0io8T0wzTxJfPGAzZg1 iVOm3yf/e7cnyqMh7nE0Yoma+2PuZpedXIQt0Q/w+Va9TzLdQnGS1rm4SOk2UScTgq GHwA803UJ9ulEW2wJEybDpAawgc/uSHcN1ejmQlc= Received: from mail-qk1-x742.google.com (mail-qk1-x742.google.com [IPv6:2607:f8b0:4864:20::742]) by sourceware.org (Postfix) with ESMTPS id 64E9A388A82B for ; Wed, 3 Jun 2020 17:52:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 64E9A388A82B Received: by mail-qk1-x742.google.com with SMTP id w1so3075806qkw.5 for ; Wed, 03 Jun 2020 10:52:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:cc:references:from:autocrypt:subject :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=t1PRLtMyKYF+0avmN8bIyIwujoUeD3MKlf+TttUCwPE=; b=NzyAl0ak+04oKPAP6tYI9YVFKdXYZQr75QUyTfCXoBipJrbN0KSUi9AG/UIjuQdGz3 tfhpwR3SrmYOAViaMX9X/CHv7UgfLBiqIdZszMAKuypE++Sm9i1hu/y/ifDdm0viyFPn hQt4FIKBuHN08dSjnFtaqqYeQih//h89HglXi7VlY9AkCBi04iPZBll83qmfpPZ+y5yv 6R5x+PmUL2vFDxaE2RTaRTcDmK9Sefn2egY3yF51T1P5Nlso5XYhjeW0zfuX1PuWKTZQ rhccj2050KKy9lP/RtDoOCqP/XEgumO54PLtLOLcZPBem6eWaTBjQ0vqfT45hMOHpkDA 32kA== X-Gm-Message-State: AOAM532CyPtCr1bDXxWsukcE7CWQGAijYsNPrYuw2qA/794ivVOdfIIy 1HCJfD1gI3PoeC9fBpwBMjrgGBYsHrc= X-Google-Smtp-Source: ABdhPJwyBEi+Vnk5UmWzzZkh+OzwwBiACz2TUzh0xqU7zSoB3C+SwqbkWi1SoEaKwhj6WdVM9xgKlA== X-Received: by 2002:a37:70c5:: with SMTP id l188mr880787qkc.396.1591206729398; Wed, 03 Jun 2020 10:52:09 -0700 (PDT) Received: from [192.168.1.4] ([177.194.48.209]) by smtp.googlemail.com with ESMTPSA id j5sm2504417qtr.73.2020.06.03.10.52.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 03 Jun 2020 10:52:08 -0700 (PDT) To: Florian Weimer References: <2c218c9ed9586ed5491f6fa08045d1e883b126c3.1589998207.git.fweimer@redhat.com> <724ecd59-d6e4-9f52-f425-8a4ff795114f@linaro.org> <87wo5577m3.fsf@oldenburg2.str.redhat.com> <87r1uwtajw.fsf@oldenburg2.str.redhat.com> Autocrypt: addr=adhemerval.zanella@linaro.org; prefer-encrypt=mutual; keydata= mQINBFcVGkoBEADiQU2x/cBBmAVf5C2d1xgz6zCnlCefbqaflUBw4hB/bEME40QsrVzWZ5Nq 8kxkEczZzAOKkkvv4pRVLlLn/zDtFXhlcvQRJ3yFMGqzBjofucOrmdYkOGo0uCaoJKPT186L NWp53SACXguFJpnw4ODI64ziInzXQs/rUJqrFoVIlrPDmNv/LUv1OVPKz20ETjgfpg8MNwG6 iMizMefCl+RbtXbIEZ3TE/IaDT/jcOirjv96lBKrc/pAL0h/O71Kwbbp43fimW80GhjiaN2y WGByepnkAVP7FyNarhdDpJhoDmUk9yfwNuIuESaCQtfd3vgKKuo6grcKZ8bHy7IXX1XJj2X/ BgRVhVgMHAnDPFIkXtP+SiarkUaLjGzCz7XkUn4XAGDskBNfbizFqYUQCaL2FdbW3DeZqNIa nSzKAZK7Dm9+0VVSRZXP89w71Y7JUV56xL/PlOE+YKKFdEw+gQjQi0e+DZILAtFjJLoCrkEX w4LluMhYX/X8XP6/C3xW0yOZhvHYyn72sV4yJ1uyc/qz3OY32CRy+bwPzAMAkhdwcORA3JPb kPTlimhQqVgvca8m+MQ/JFZ6D+K7QPyvEv7bQ7M+IzFmTkOCwCJ3xqOD6GjX3aphk8Sr0dq3 4Awlf5xFDAG8dn8Uuutb7naGBd/fEv6t8dfkNyzj6yvc4jpVxwARAQABtElBZGhlbWVydmFs IFphbmVsbGEgTmV0dG8gKExpbmFybyBWUE4gS2V5KSA8YWRoZW1lcnZhbC56YW5lbGxhQGxp bmFyby5vcmc+iQI3BBMBCAAhBQJXFRpKAhsDBQsJCAcDBRUKCQgLBRYCAwEAAh4BAheAAAoJ EKqx7BSnlIjv0e8P/1YOYoNkvJ+AJcNUaM5a2SA9oAKjSJ/M/EN4Id5Ow41ZJS4lUA0apSXW NjQg3VeVc2RiHab2LIB4MxdJhaWTuzfLkYnBeoy4u6njYcaoSwf3g9dSsvsl3mhtuzm6aXFH /Qsauav77enJh99tI4T+58rp0EuLhDsQbnBic/ukYNv7sQV8dy9KxA54yLnYUFqH6pfH8Lly sTVAMyi5Fg5O5/hVV+Z0Kpr+ZocC1YFJkTsNLAW5EIYSP9ftniqaVsim7MNmodv/zqK0IyDB GLLH1kjhvb5+6ySGlWbMTomt/or/uvMgulz0bRS+LUyOmlfXDdT+t38VPKBBVwFMarNuREU2 69M3a3jdTfScboDd2ck1u7l+QbaGoHZQ8ZNUrzgObltjohiIsazqkgYDQzXIMrD9H19E+8fw kCNUlXxjEgH/Kg8DlpoYJXSJCX0fjMWfXywL6ZXc2xyG/hbl5hvsLNmqDpLpc1CfKcA0BkK+ k8R57fr91mTCppSwwKJYO9T+8J+o4ho/CJnK/jBy1pWKMYJPvvrpdBCWq3MfzVpXYdahRKHI ypk8m4QlRlbOXWJ3TDd/SKNfSSrWgwRSg7XCjSlR7PNzNFXTULLB34sZhjrN6Q8NQZsZnMNs TX8nlGOVrKolnQPjKCLwCyu8PhllU8OwbSMKskcD1PSkG6h3r0AquQINBFcVGkoBEACgAdbR Ck+fsfOVwT8zowMiL3l9a2DP3Eeak23ifdZG+8Avb/SImpv0UMSbRfnw/N81IWwlbjkjbGTu oT37iZHLRwYUFmA8fZX0wNDNKQUUTjN6XalJmvhdz9l71H3WnE0wneEM5ahu5V1L1utUWTyh VUwzX1lwJeV3vyrNgI1kYOaeuNVvq7npNR6t6XxEpqPsNc6O77I12XELic2+36YibyqlTJIQ V1SZEbIy26AbC2zH9WqaKyGyQnr/IPbTJ2Lv0dM3RaXoVf+CeK7gB2B+w1hZummD21c1Laua +VIMPCUQ+EM8W9EtX+0iJXxI+wsztLT6vltQcm+5Q7tY+HFUucizJkAOAz98YFucwKefbkTp eKvCfCwiM1bGatZEFFKIlvJ2QNMQNiUrqJBlW9nZp/k7pbG3oStOjvawD9ZbP9e0fnlWJIsj 6c7pX354Yi7kxIk/6gREidHLLqEb/otuwt1aoMPg97iUgDV5mlNef77lWE8vxmlY0FBWIXuZ yv0XYxf1WF6dRizwFFbxvUZzIJp3spAao7jLsQj1DbD2s5+S1BW09A0mI/1DjB6EhNN+4bDB SJCOv/ReK3tFJXuj/HbyDrOdoMt8aIFbe7YFLEExHpSk+HgN05Lg5TyTro8oW7TSMTk+8a5M kzaH4UGXTTBDP/g5cfL3RFPl79ubXwARAQABiQIfBBgBCAAJBQJXFRpKAhsMAAoJEKqx7BSn lIjvI/8P/jg0jl4Tbvg3B5kT6PxJOXHYu9OoyaHLcay6Cd+ZrOd1VQQCbOcgLFbf4Yr+rE9l mYsY67AUgq2QKmVVbn9pjvGsEaz8UmfDnz5epUhDxC6yRRvY4hreMXZhPZ1pbMa6A0a/WOSt AgFj5V6Z4dXGTM/lNManr0HjXxbUYv2WfbNt3/07Db9T+GZkpUotC6iknsTA4rJi6u2ls0W9 1UIvW4o01vb4nZRCj4rni0g6eWoQCGoVDk/xFfy7ZliR5B+3Z3EWRJcQskip/QAHjbLa3pml xAZ484fVxgeESOoaeC9TiBIp0NfH8akWOI0HpBCiBD5xaCTvR7ujUWMvhsX2n881r/hNlR9g fcE6q00qHSPAEgGr1bnFv74/1vbKtjeXLCcRKk3Ulw0bY1OoDxWQr86T2fZGJ/HIZuVVBf3+ gaYJF92GXFynHnea14nFFuFgOni0Mi1zDxYH/8yGGBXvo14KWd8JOW0NJPaCDFJkdS5hu0VY 7vJwKcyHJGxsCLU+Et0mryX8qZwqibJIzu7kUJQdQDljbRPDFd/xmGUFCQiQAncSilYOcxNU EMVCXPAQTteqkvA+gNqSaK1NM9tY0eQ4iJpo+aoX8HAcn4sZzt2pfUB9vQMTBJ2d4+m/qO6+ cFTAceXmIoFsN8+gFN3i8Is3u12u8xGudcBPvpoy4OoG Subject: Re: [PATCH 2/2] manual: Document __libc_single_threaded Message-ID: Date: Wed, 3 Jun 2020 14:52:05 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <87r1uwtajw.fsf@oldenburg2.str.redhat.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Adhemerval Zanella via Libc-alpha Reply-To: Adhemerval Zanella Cc: Adhemerval Zanella via Libc-alpha Errors-To: libc-alpha-bounces@sourceware.org Sender: "Libc-alpha" On 03/06/2020 12:48, Florian Weimer wrote: > * Adhemerval Zanella: > >>> I'm going to add this to the manual as an implementation note, after the >>> first example: >>> >>> @c Note: No memory order on __libc_single_threaded. The >>> @c implementation must ensure that exit of the critical >>> @c (second-to-last) thread happens-before setting >>> @c __libc_single_threaded to true. Otherwise, acquire MO might be >>> @c needed for reading the variable in some scenarios, and that would >>> @c completely defeat its purpose. >> >> The comments is sound, but I still think we should properly document >> that this initial version does not attempt to update >> __libc_single_threaded on pthread_join or detach exit and maybe also >> the brief explanation you added on why this semantic was chose (to >> avoid the requirement of more strict MO). > > I'm concerned that if we make the implementation too transparent, > programmers will read the explanation and say, “gosh, I better assign > true to __libc_single_threaded after I joined the last thread”. That's > not something we want to encourage. In fact from your discussion with Rich I think we really should be transparent about its semantic, why he have chose the qualifiers (whether we use volatile or not), how glibc updates internally, and the expected usage patterns (for instance program are not expected to change its value). > >>> For detached thread exits, this kind of synchronization may not be >>> easily obtainable in all cases. I don't think we can do it on the >>> on-thread exit path because the kernel will perform certain actions >>> afterwards (like robust mutex updates), no matter how late we do it. I >>> guess we could perhaps piggy-back on the stack reclamation mechanism. >> >> It seems that robust mutexes updates are indeed a problem, but I am not >> sure if CLONE_CHILD_CLEARTID clear helps here. It signals the thread >> is done with the memory synchronization, but the stack cache is not >> really updated. Maybe an extra clone3 flag ? > > I thought we might piggy-back on the work that free_stacks does. But > the code is sufficiently convoluted that I'm no longer sure. I am not sure that the free_stack pattern is really helpful without some memory synchronization, such as SYS_membarrier. My idea of the clone3 flag would be similar to CLONE_CHILD_{CLEAR,SET}TID where kernel does the heavy lifting of the memory synchronization to update the total number of threads.