From patchwork Tue Jun 30 15:23:32 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Florian Weimer X-Patchwork-Id: 1319972 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=sourceware.org (client-ip=2620:52:3:1:0:246e:9693:128c; helo=sourceware.org; envelope-from=libc-alpha-bounces@sourceware.org; receiver=) Authentication-Results: ozlabs.org; dmarc=pass (p=none dis=none) header.from=sourceware.org Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=Fxc5RNGa; dkim-atps=neutral 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 ozlabs.org (Postfix) with ESMTPS id 49x7Rg4nyjz9sDX for ; Wed, 1 Jul 2020 01:23:43 +1000 (AEST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 834D83844072; Tue, 30 Jun 2020 15:23:41 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 834D83844072 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1593530621; bh=f8zJfW3QPih54Ea///iSzOMAz/w08s3vynulUfkfeJI=; h=To:Subject:In-Reply-To:References:Date:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=Fxc5RNGaQQZuh/+lVjZSkGdLKnWrc3+seUX+C2eF2K5QclmBctMPlF/N71bHqFkgF fXFbF4phOwBYLFRQQDwsetWDVZJW+bncZS03iPyduICqrszSQHd3Oe4wd8G5y9Q28c H24e1BrKhkLpE+x8EIMOkPWtoN93PBcrm4H55DEs= X-Original-To: libc-alpha@sourceware.org Delivered-To: libc-alpha@sourceware.org Received: from us-smtp-delivery-1.mimecast.com (us-smtp-1.mimecast.com [205.139.110.61]) by sourceware.org (Postfix) with ESMTP id D6E583846410 for ; Tue, 30 Jun 2020 15:23:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org D6E583846410 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-390-cmtDf2I1Pfad7SaLyeiuMg-1; Tue, 30 Jun 2020 11:23:35 -0400 X-MC-Unique: cmtDf2I1Pfad7SaLyeiuMg-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id CD71580183C; Tue, 30 Jun 2020 15:23:34 +0000 (UTC) Received: from oldenburg2.str.redhat.com (ovpn-112-128.ams2.redhat.com [10.36.112.128]) by smtp.corp.redhat.com (Postfix) with ESMTPS id CE3F410016EB; Tue, 30 Jun 2020 15:23:33 +0000 (UTC) To: libc-alpha@sourceware.org Subject: [PATCH V3 2/2] manual: Document __libc_single_threaded In-Reply-To: <7da60193567f54d24c8b6af2dd0f01199fdfc052.1593530401.git.fweimer@redhat.com> References: <7da60193567f54d24c8b6af2dd0f01199fdfc052.1593530401.git.fweimer@redhat.com> X-From-Line: b96fba713ce0f8b3a4c3743362745ff414b23793 Mon Sep 17 00:00:00 2001 Message-Id: Date: Tue, 30 Jun 2020 17:23:32 +0200 User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com X-Spam-Status: No, score=-12.8 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H3, 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-Patchwork-Original-From: Florian Weimer via Libc-alpha From: Florian Weimer Reply-To: Florian Weimer Errors-To: libc-alpha-bounces@sourceware.org Sender: "Libc-alpha" Reviewed-by: Szabolcs Nagy Reviewed-by: DJ Delorie --- V3: Minor wording change suggested by DJ. manual/threads.texi | 113 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 113 insertions(+) diff --git a/manual/threads.texi b/manual/threads.texi index bb7a42c655..f38d9b4d88 100644 --- a/manual/threads.texi +++ b/manual/threads.texi @@ -628,6 +628,7 @@ the standard. * Initial Thread Signal Mask:: Setting the initial mask of threads. * Waiting with Explicit Clocks:: Functions for waiting with an explicit clock specification. +* Single-Threaded:: Detecting single-threaded execution. @end menu @node Default Thread Attributes @@ -843,6 +844,118 @@ Behaves like @code{pthread_timedjoin_np} except that the absolute time in @var{abstime} is measured against the clock specified by @var{clockid}. @end deftypefun +@node Single-Threaded +@subsubsection Detecting Single-Threaded Execution + +Multi-threaded programs require synchronization among threads. This +synchronization can be costly even if there is just a single thread +and no data is shared between multiple processors. @Theglibc{} offers +an interface to detect whether the process is in single-threaded mode. +Applications can use this information to avoid synchronization, for +example by using regular instructions to load and store memory instead +of atomic instructions, or using relaxed memory ordering instead of +stronger memory ordering. + +@deftypevar char __libc_single_threaded +@standards{GNU, sys/single_threaded.h} +This variable is non-zero if the current process is definitely +single-threaded. If it is zero, the process may be multi-threaded, +or @theglibc{} cannot determine at this point of the program execution +whether the process is single-threaded or not. + +Applications must never write to this variable. +@end deftypevar + +Most applications should perform the same actions whether or not +@code{__libc_single_threaded} is true, except with less +synchronization. If this rule is followed, a process that +subsequently becomes multi-threaded is already in a consistent state. +For example, in order to increment a reference count, the following +code can be used: + +@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 + +@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. + +This still requires some form of synchronization on the +single-threaded branch, so it can be beneficial not to declare the +reference count as @code{_Atomic}, and use the GCC @code{__atomic} +built-ins. @xref{__atomic Builtins,, Built-in Functions for Memory +Model Aware Atomic Operations, gcc, Using the GNU Compiler Collection +(GCC)}. Then the code to increment a reference count looks like this: + +@smallexample +if (__libc_single_threaded) + ++refeference_count; +else + __atomic_fetch_add (&reference_count, 1, __ATOMIC_ACQ_REL); +@end smallexample + +(Depending on the data associated with the reference count, it may be +possible to use the weaker @code{__ATOMIC_RELAXED} memory ordering on +the multi-threaded branch.) + +Several functions in @theglibc{} can change the value of the +@code{__libc_single_threaded} variable. For example, creating new +threads using the @code{pthread_create} or @code{thrd_create} function +sets the variable to false. This can also happen indirectly, say via +a call to @code{dlopen}. Therefore, applications need to make a copy +of the value of @code{__libc_single_threaded} if after such a function +call, behavior must match the value as it was before the call, like +this: + +@smallexample +bool single_threaded = __libc_single_threaded; +if (single_threaded) + prepare_single_threaded (); +else + prepare_multi_thread (); + +void *handle = dlopen (shared_library_name, RTLD_NOW); +lookup_symbols (handle); + +if (single_threaded) + cleanup_single_threaded (); +else + cleanup_multi_thread (); +@end smallexample + +Since the value of @code{__libc_single_threaded} can change from true +to false during the execution of the program, it is not useful for +selecting optimized function implementations in IFUNC resolvers. + +Atomic operations can also be used on mappings shared among +single-threaded processes. This means that a compiler must not use +@code{__libc_single_threaded} to optimize atomic operations, unless it +is able to prove that the memory is not shared. + +@strong{Implementation Note:} The @code{__libc_single_threaded} +variable is not declared as @code{volatile} because it is expected +that compilers optimize a sequence of single-threaded checks into one +check, for example if several reference counts are updated. The +current implementation in @theglibc{} does not set the +@code{__libc_single_threaded} variable to a true value if a process +turns single-threaded again. Future versions of @theglibc{} may do +this, but only as the result of function calls which imply an acquire +(compiler) barrier. (Some compilers assume that well-known functions +such as @code{malloc} do not write to global variables, and setting +@code{__libc_single_threaded} would introduce a data race and +undefined behavior.) In any case, an application must not write to +@code{__libc_single_threaded} even if it has joined the last +application-created thread because future versions of @theglibc{} may +create background threads after the first thread has been created, and +the application has no way of knowning that these threads are present. + @c FIXME these are undocumented: @c pthread_atfork @c pthread_attr_destroy