From patchwork Wed Jun 24 13:03:55 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Florian Weimer X-Patchwork-Id: 39784 Return-Path: X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 5B9C43987462; Wed, 24 Jun 2020 13:04:07 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 5B9C43987462 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1593003847; bh=T8DIbMBbFnmkeLQQEVu++XrICNdHCcshYeLs/9TaYJI=; h=To:Subject:In-Reply-To:References:Date:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=KXrtgcGVbOcB55G5zY00IdjEmgiCyP4oO6aOgsunX7wbHgct8+q9F2TXGs1c/T03E bDc7dFOJmpFp7kqLOXATki3/cbUhO+lp4vrXblinaOElv3SWBsMqoZmFIcnNPXV3uE hjiQzmGOqviwWOxMfOSDC8xi4p/S5ShMCJrE1v8o= X-Original-To: libc-alpha@sourceware.org Delivered-To: libc-alpha@sourceware.org Received: from us-smtp-1.mimecast.com (us-smtp-1.mimecast.com [207.211.31.81]) by sourceware.org (Postfix) with ESMTP id 5314B3938C10 for ; Wed, 24 Jun 2020 13:04:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 5314B3938C10 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-25-MQzHbFgFMSGfr_Zzr7CF2w-1; Wed, 24 Jun 2020 09:03:58 -0400 X-MC-Unique: MQzHbFgFMSGfr_Zzr7CF2w-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id B4BC4107ACF8; Wed, 24 Jun 2020 13:03:57 +0000 (UTC) Received: from oldenburg2.str.redhat.com (ovpn-113-18.ams2.redhat.com [10.36.113.18]) by smtp.corp.redhat.com (Postfix) with ESMTPS id E2F3C79318; Wed, 24 Jun 2020 13:03:56 +0000 (UTC) To: libc-alpha@sourceware.org Subject: [PATCH v2 2/2] manual: Document __libc_single_threaded In-Reply-To: <83bce1862dcd7c4c982334382b919785cc666588.1593003514.git.fweimer@redhat.com> References: <83bce1862dcd7c4c982334382b919785cc666588.1593003514.git.fweimer@redhat.com> Message-Id: <99b00049f399fd0acffb2c27530f8fd7a64018f8.1593003514.git.fweimer@redhat.com> Date: Wed, 24 Jun 2020 15:03:55 +0200 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.11 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com X-Spam-Status: No, score=-12.9 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 Cc: Michael Kerrisk Errors-To: libc-alpha-bounces@sourceware.org Sender: "Libc-alpha" --- V2: Fix typos. Add the requestion documentation of implementation details. manual/threads.texi | 113 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 113 insertions(+) Reviewed-by: Szabolcs Nagy diff --git a/manual/threads.texi b/manual/threads.texi index bb7a42c655..009026deb8 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 cannot 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