From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.120]) by sourceware.org (Postfix) with ESMTP id BC1D73840C37 for ; Thu, 21 May 2020 14:03:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org BC1D73840C37 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-500-FyaXo9CxNmajZQi8vcO05A-1; Thu, 21 May 2020 10:03:09 -0400 X-MC-Unique: FyaXo9CxNmajZQi8vcO05A-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 0C02A8005AA; Thu, 21 May 2020 14:03:08 +0000 (UTC) Received: from oldenburg2.str.redhat.com (ovpn-114-30.ams2.redhat.com [10.36.114.30]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 2942F5C1B0; Thu, 21 May 2020 14:03:07 +0000 (UTC) From: Florian Weimer To: Adhemerval Zanella Cc: Szabolcs Nagy , libc-alpha@sourceware.org Subject: Re: [PATCH 2/2] manual: Document __libc_single_threaded References: <2c218c9ed9586ed5491f6fa08045d1e883b126c3.1589998207.git.fweimer@redhat.com> <724ecd59-d6e4-9f52-f425-8a4ff795114f@linaro.org> <20200521130927.GF14130@arm.com> <39687760-f8b1-4209-8798-ed8a16b87b57@linaro.org> <20200521133046.GH14130@arm.com> <87k115768f.fsf@oldenburg2.str.redhat.com> <419c660c-1e1b-46e7-aafc-8deadb1a9767@linaro.org> Date: Thu, 21 May 2020 16:03:05 +0200 In-Reply-To: <419c660c-1e1b-46e7-aafc-8deadb1a9767@linaro.org> (Adhemerval Zanella's message of "Thu, 21 May 2020 10:58:37 -0300") Message-ID: <87d06x75d2.fsf@oldenburg2.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-8.9 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org 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: , X-List-Received-Date: Thu, 21 May 2020 14:03:15 -0000 * Adhemerval Zanella: > On 21/05/2020 10:44, Florian Weimer wrote: >> * Szabolcs Nagy: >> >>> The 05/21/2020 10:15, Adhemerval Zanella wrote: >>>> On 21/05/2020 10:09, Szabolcs Nagy wrote: >>>>> The 05/21/2020 09:50, Adhemerval Zanella via Libc-alpha wrote: >>>>>> 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)? >>>>> >>>>> not if we guarantee that this object can only be >>>>> written while the process is single threaded. >>>>> >>>>> (e.g. an exiting detached thread cannot update it >>>>> even if only one thread left.. because that may >>>>> concurrently read it) >>>>> >>>> >>>> OK, so I think we should outline that atomic operations are not required >>>> to acess this object and that once __libc_single_threaded is set 0 it will >>>> continue to indicate non-single thread even thread are jointed or detached >>>> thread finishes. >>> >>> what's wrong with pthread_join updating it? >> >> It's tricky do it correctly if there are two remaining threads, one of >> them the one being joined, the other one a detached thread. A >> straightforward implementation merely looking at __nptl_nthreads before >> returning from pthread_join would not perform the required >> synchronization on the detached thread exit. > > Couldn't we accomplish by making __libc_single_threaded count the total > number of threads and making pthread_create/pthread_exit/detach exit > atomically updating it? We already have __nptl_nthreads as a global thread count, but it is currently decremented too early (on the exiting thread). As I tried to explain, we cannot decrement it on the exiting thread itself because it would not give us the desired synchronization, particularly not with any kernel actions that happen afterwards. Thanks, Florian