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 166B8383E80F for ; Mon, 25 May 2020 17:21:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 166B8383E80F 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: Mon, 25 May 2020 13:21:49 -0400 From: Rich Felker To: Florian Weimer Cc: libc-alpha@sourceware.org Subject: Re: [PATCH 2/2] manual: Document __libc_single_threaded Message-ID: <20200525172149.GQ1079@brightrain.aerifal.cx> References: <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> <20200523160202.GG1079@brightrain.aerifal.cx> <87o8qczb0n.fsf@oldenburg2.str.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87o8qczb0n.fsf@oldenburg2.str.redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-6.2 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: Mon, 25 May 2020 17:21:51 -0000 On Mon, May 25, 2020 at 10:08:37AM +0200, Florian Weimer via Libc-alpha wrote: > * Rich Felker: > > >> 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). > > Sorry about that, hit C-c C-c while I thought I was in a terminal. 8-/ > > For most standard C functions, it is well-known to which global > variables (if any) they write. Of course, compilers exploit this fact. > > > 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; > > And of course malloc is the most common example of a standard function > that has observable side effects beyond those specified in the standard: > most implementations have a statistics interface. > > > at worst you see the old value of __libc_single_threaded (false) > > rather than the new one (true) and that direction is safe. > > It's still a data race. The compiler can easily generate invalid code > if it incorrectly assumes that __libc_single_threaded remains stable. I > don't know if Clang will do this. But I think the C library > implementation should be rather conservative here. If this is an issue, and even regardless of whether it is, I think the type of __libc_single_threaded should be volatile qualified. This ensures that it cannot be cached in any way that might be invalid. That's not just a hack; it's the correct way to model that the value is able to change asynchronously (such as by an operation that the compiler would otherwise assume can't have side effects). Rich