From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from brightrain.aerifal.cx (brightrain.aerifal.cx [216.12.86.13]) by sourceware.org (Postfix) with ESMTPS id EF4B23851C0C for ; Fri, 22 May 2020 17:49:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org EF4B23851C0C Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=libc.org Authentication-Results: sourceware.org; spf=none smtp.mailfrom=dalias@libc.org Date: Fri, 22 May 2020 13:49:32 -0400 From: Rich Felker To: Florian Weimer Cc: libc-alpha@sourceware.org Subject: Re: [PATCH 2/2] manual: Document __libc_single_threaded Message-ID: <20200522174932.GY1079@brightrain.aerifal.cx> References: <20200521133046.GH14130@arm.com> <87k115768f.fsf@oldenburg2.str.redhat.com> <20200522100146.GA29518@arm.com> <877dx45low.fsf@oldenburg2.str.redhat.com> <20200522105458.GB29518@arm.com> <20200522150720.GR1079@brightrain.aerifal.cx> <20200522161413.GU1079@brightrain.aerifal.cx> <871rnb3nue.fsf@oldenburg2.str.redhat.com> <20200522172826.GW1079@brightrain.aerifal.cx> <87h7w727i4.fsf@oldenburg2.str.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87h7w727i4.fsf@oldenburg2.str.redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-6.8 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=no 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: Fri, 22 May 2020 17:49:36 -0000 On Fri, May 22, 2020 at 07:40:19PM +0200, Florian Weimer via Libc-alpha wrote: > * Rich Felker: > > >> Our discussion focused on the problem that observing a thread count of 1 > >> in pthread_join does not necessarily mean that it is safe to assume at > >> this point that the process is single-threaded, in glibc's > >> implementation that uses a simple __nptl_nthreads counter decremented on > >> the thread itself. This does not cause a low-level data race directly, > >> but is potentially still incorrect (I'm not quite sure yet). > > > > pthread_join necessarily has an acquire barrier (this is a fundamental > > requirement of the interface contract; join is acquiring the results > > of the thread) so under some weak assumptions on unsynchronized memory > > access (e.g. non-tearing, not seeing a value that wasn't stored > > sometime between the last and next acquire barriers on the observer's > > side) I think observing it from pthread_join is safe. > > Because of the meaning of the variable, it is *completely* safe if there > are no detached threads, without any further assumptions. > > With detached threads an pthread_join observing a thread count of 1 (as > decreased during thread exit), the validity of setting > __libc_single_threaded depends on whether the kernel offers something > that causes a memory write on thread exit. I know of at least two such I don't follow. Why do you care about the kernel entity exiting here? You should only care about having a release barrier before the update to the count, so that seeing the updated count guarantees seeing any changes to memory made by the exiting detached thread. Rich