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 790753851C16 for ; Sat, 23 May 2020 16:02:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 790753851C16 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: Sat, 23 May 2020 12:02:03 -0400 From: Rich Felker To: Szabolcs Nagy Cc: Szabolcs Nagy , Florian Weimer , libc-alpha@sourceware.org Subject: Re: [PATCH 2/2] manual: Document __libc_single_threaded Message-ID: <20200523160202.GG1079@brightrain.aerifal.cx> References: <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> <20200522174932.GY1079@brightrain.aerifal.cx> <20200522192249.GC24880@arm.com> <20200522195326.GB1079@brightrain.aerifal.cx> <20200523064941.GD26190@port70.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200523064941.GD26190@port70.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-6.5 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: Sat, 23 May 2020 16:02:07 -0000 On Sat, May 23, 2020 at 08:49:41AM +0200, Szabolcs Nagy wrote: > * Rich Felker [2020-05-22 15:53:26 -0400]: > > On Fri, May 22, 2020 at 08:22:50PM +0100, Szabolcs Nagy wrote: > > > so i think the safest implementation never sets > > > __libc_single_threaded back to true and second safest > > > is one that only sets it back to true in pthread_join > > > when there were no detached threads (or if using some > > > os api it can verify that there really is only one > > > kernel thread). > > > > > > if we want to allow kernel entities to be around > > > but still tell the user when "as far as the libc > > > is concerned there is only one thread", then i > > > think __libc_single_threaded needs to be an extern > > > call (that acts as a compiler barrier). > > > > Do relaxed order atomics provide a compiler barrier? If so, I think > > SYS_membarrier combined with one could be sufficient However using > > atomic type for a public interface like this is a bit of a > > compatibility thorn (requires compiler and std level supporting it). > > > > Of course the same could be achieved with requirement to use a manual > > compiler barrier (dummy asm) but I think it's error-prone to assume > > the application would do it correctly. > > no, relaxed atomics do not order unrelated memory accesses. > > but a trick like you proposed for the musl internal need_locks > may work: __libc_single_threaded can go back to 1 when there > is only one thread left executing user code *and* that thread > called a libc function that has an acquire barrier. > (if thread exit has a release barrier then this should work) Thread exit is necessarily a release barrier if the thread is joinable, has robust mutexes, or any of a number of other conditions (including anything where the child exit futex address is non-null). In addition any barrier in userspace before the kernel task exit is fine too. > this can allow earlier single threaded detection than only > considering pthread_join: e.g. stdio, malloc etc may do a > check and update the global after an acquire barrier, however > the compiler must not cache globals across libc calls for this > to work. It can't cache globals across non-pure functions whose definitions it cant't see (and if it saw the definition it would know the global is modified). malloc is something of a special case where clang treats it not as a function but having "pure malloc semantics", but even then I don't think it matters if it caches it; at worst you see the old value of __libc_single_threaded (false) rather than the new one (true) and that direction is safe. Rich