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.1 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 [IPv6:2620:52:3:1:0:246e:9693:128c]) (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 169901F55B for ; Thu, 21 May 2020 14:32:12 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id E26E7397241F; Thu, 21 May 2020 14:32:09 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E26E7397241F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1590071529; bh=MIOi2ruylYioVNeUHrgWSuB5BXq0OKpKHFUbFOlRwlE=; h=To:References:Subject:Date:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=Pu7vjSTm17nMu24zB7/Hsmn1qSMaZlMnXkfMbbZRgK0vFcwV8Ib35j12SOE+U+q0E iNVg/jfw6v70CZx+muajwZ7q/aeLfUhTyx31NKgd4IMJF3rXysNP12/ksgiEfgIwte jRKsRI0TuWSFqonaQyD9Tp1UemZ5rSTiKTR84fRU= Received: from mail-qk1-x743.google.com (mail-qk1-x743.google.com [IPv6:2607:f8b0:4864:20::743]) by sourceware.org (Postfix) with ESMTPS id A2DA4383E800 for ; Thu, 21 May 2020 14:32:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org A2DA4383E800 Received: by mail-qk1-x743.google.com with SMTP id w3so1850537qkb.6 for ; Thu, 21 May 2020 07:32:06 -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:references:from:autocrypt:subject:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=MIOi2ruylYioVNeUHrgWSuB5BXq0OKpKHFUbFOlRwlE=; b=KQc5VmkW+7F8TJAS20mjMZwQMWie4a4uG8DF6enMHmjjs65VNQODehmIZ/Yd7vfS1y DsEpMsoAjydFjzFAkg3EPKtUU995ys2IDvBdL7zSaV2X2bElo6Jidg6hKW8I6yKB/jXW 5Oww+pD3M3q5qktCYPW4G93il4Dw7HLi9nHNL7cXc/B/1ku2hHZHo5Egr99gHw1cTgyC vYXZ9NVPIaPYDh6apFec33hbCTlruTCnulFLRM19Vs0i8/Ta6a/pf8mHcxUXynAf6ySa galYyKmr1LWvkVkW0baH8WdUaY1neT8NVrnOSgkduGArwsUEkrQnHOYgmuag/mj9vGYm EwbA== X-Gm-Message-State: AOAM533LBlnpnh0c7CRvga56UVaX0MuXrtck5YJ4W9aJfWPLdLOvQoRX h9OsiR421qnl/825j7GuFqP1VpJnwJU= X-Google-Smtp-Source: ABdhPJywQcVsLMCVY1j5gCEBnWTO8vtFAUEjvl2FGcV9+g1aYUXmqgGGweQdqRzIEyW0ZGPeJLY74A== X-Received: by 2002:a37:a710:: with SMTP id q16mr2003129qke.23.1590071525955; Thu, 21 May 2020 07:32:05 -0700 (PDT) Received: from [192.168.1.4] ([177.194.48.209]) by smtp.googlemail.com with ESMTPSA id 99sm5010593qte.93.2020.05.21.07.32.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 21 May 2020 07:32:05 -0700 (PDT) To: Florian Weimer , Adhemerval Zanella via Libc-alpha References: <2c218c9ed9586ed5491f6fa08045d1e883b126c3.1589998207.git.fweimer@redhat.com> <724ecd59-d6e4-9f52-f425-8a4ff795114f@linaro.org> <87wo5577m3.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: Thu, 21 May 2020 11:32:02 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <87wo5577m3.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 Errors-To: libc-alpha-bounces@sourceware.org Sender: "Libc-alpha" On 21/05/2020 10:14, Florian Weimer wrote: > * Adhemerval Zanella via Libc-alpha: > >> On 20/05/2020 15:12, Florian Weimer via Libc-alpha wrote: >> >>> +@smallexample >>> +if (__libc_single_threaded) >>> + atomic_fetch_add (&reference_count, 1, memory_order_relaxed); >>> +else >>> + atomic_fetch_add (&reference_count, 1, memory_order_acq_rel); >>> +@end smallexample >> >> Shouldn't the access to __libc_single_threaded be atomic itself >> (at least with relaxed semantic)? > > Good question. In the current implementation, it is not needed because > the variable is never written again once the process is multi-threaded. > > We must retain relaxed MO access as a valid use of this variable. A > future implementation may set __libc_single_threaded to true after > detecting that the process has become single-threaded again. But I > think this requires that the last remaining thread synchronizes in some > way with the exit of the other, second-to-last remaining thread. And > that in turn means that no explicit MO is needed for the variable read. > > 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). > > 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 ?