From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.codeweavers.com (mail.codeweavers.com [65.103.31.132]) by sourceware.org (Postfix) with ESMTPS id 045A83858403; Mon, 24 Oct 2022 20:51:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 045A83858403 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=codeweavers.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=codeweavers.com DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=codeweavers.com; s=6377696661; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:From:References:Cc:To:Subject:MIME-Version:Date:Message-ID:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=mDle7FJ4HNuSLYRdmsvnR0I3mlJyJq0ea8Zj/a7uegw=; b=LRb7GI2QWUMyc3k/W6lUN+Kljv 5XyJCd5aPg0So+LlWFTKrYtHQOlI+kiwFxglTnZeG5IsHy8zKpomn6XFOJpJzGXAB8NDqy4d2zI9Z FZXDcsV6C1Zpw7aG9DOherJQ1YAp7RFCtVMoF3xvN527bZtFQkSmqXNpl7VteEEevoeQ=; Received: from cw141ip133.vpn.codeweavers.com ([10.69.141.133]) by mail.codeweavers.com with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1on4Q0-009EE3-0P; Mon, 24 Oct 2022 15:51:32 -0500 Message-ID: <4651c417-6dcf-4570-1796-43bfa140c6fc@codeweavers.com> Date: Mon, 24 Oct 2022 22:50:16 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.3.1 Subject: Re: Adding a new thread model to GCC Content-Language: en-GB To: LIU Hao , i.nixman@autistici.org, "mingw-w64-public@lists.sourceforge.net" Cc: Wakely , libstdc++@gcc.gnu.org, gcc-patches@gcc.gnu.org, Eric Botcazou References: <0f1f223a-3756-1da3-bd1d-b87edd34e1f9@126.com> <7277b1d9a835d8cc651ab112eac8c2e7@autistici.org> <3d80a59c-39f4-85e0-3558-062ddcd5ece7@126.com> <496a1d58-674a-cdb2-1e00-873bd5870ac3@126.com> <8a3105e7-c7aa-7f70-d8ae-2808ca126291@126.com> From: Jacek Caban In-Reply-To: <8a3105e7-c7aa-7f70-d8ae-2808ca126291@126.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_SHORT,NICE_REPLY_A,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 10/24/22 05:40, LIU Hao via Gcc-patches wrote: > 在 2022/10/21 20:34, i.nixman@autistici.org 写道: >> >> got it... >> anyway it seems logical to me the way I proposed :) >> >> > > Below is a message forwarded from mingw-w64-public, elaborating the > necessity of a new thread model. > > As there are objections from other mingw-w64 developers, I am putting > those patches against mingw-w64-crt on hold for now. Despite that, all > threading facilities - mutexes, condition variables, once flags, etc. > - are still fully functional within the mcf thread model. > > In addition, I will keep maintaining my personal builds (from GCC 12 > release branch) with these patches at https://gcc-mcf.lhmouse.com/. > > > -------- Forwarded Message -------- > 在 2022/10/23 18:06, Jacek Caban 写道: > > > > Please, let's not do that. It's possible to fix existing > implementations, we don't need to make > > things more complicated than they are. > > > > Okay okay, I think I have to compose a thorough list of problems that > we are facing at the moment, and had better have a permalink to the > mailing list archive that I can reference elsewhere. I have been tired > of repeating the same grounds of arguments again and again: > > > 1. In a DLL, destructors of static objects and callbacks that are > registered >     with `atexit()`, are executed by `LdrShutdownProcess()`, after all > the other >     thread have been terminated `ZwTerminateProcessO(NULL, status)`. > This means >     that, if another thread has been terminated while holding a mutex, > the mutex >     can never get unlocked. If a destructor attempts to lock the same > mutex, >     deadlocks will occur. Destructors of executables do not suffer > from this >     issue, because they are executed before `RtlExitUserProcess()`. > >     Standard behavior: Static destructors and exit callbacks should be > executed >     while other threads are running. If another thread attempts to > access a >     destroyed object, the behavior is undefined; the user is > responsible to >     prevent this from happening, by joining or suspending it. > > > 2. Following 1, in a DLL, static destructors and exit callbacks are still >     invoked when `_Exit()` or `quick_exit()` is called. > >     Standard behavior: `_Exit()` should not perform any cleanup; not > even open >     files are flushed. `quick_exit()` shall invoke all quick-exit > callbacks in >     reverse order, then call `_Exit()`. > > > 3. There is a use-after-free bug [1] about thread-local destructors. I > suspect >     this is caused by emutls, because GCC uses `__cxa_thread_atexit()` to >     register thread-local destructors, which could interleave with >     `emutls_destroy()`. > >     Standard behavior: This is not allowed to happen. mcfgthread > solves this >     issue by running thread-local destructors and thread-specific key >     destructors as two separate passes [3]. > >     [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80816 >     [2] > https://github.com/gcc-mirror/gcc/blob/f84e4fb44aa26b71fbc64e0532fd24d96e5caa3f/libgcc/emutls.c#L96 >     [3] > https://github.com/lhmouse/mcfgthread/blob/63e034d375caf585e2921cd3455f1048feb2172d/src/xglobals.c#L249 > > > 4. In the win32 thread model, thread-specific key destructors are > called at >     process exit [4], after static destructors. > >     Standard behavior: They shall be called only when a thread exits, > and the >     associated thread-specific values are not a null pointer. They > shall not be >     called when a program terminates; instead, users are responsible for >     deallocating such resources before calling `exit()`. This > requirement is >     missing in POSIX, but formally specified by ISO/IEC 9899:2017, as > the 4th >     paragraph in '7.26.6.1 The tss_create function'. > >     [4] > https://github.com/mingw-w64/mingw-w64/blob/d0a034a04d312434b842c4869a8a900568d8db98/mingw-w64-crt/crt/tlsthrd.c#L134 Those 4 points describes problems that you solve in the new threading model, but there is no reason they can't be fixed for existing threading models. In fact, ideally they would be fixed for all threading models. Except now we need to worry about one more threading model, meaning that future bugs will be even harder to fix. > > 5. Wait operations, of timed mutexes and condition variables, should take >     absolute time points as `struct timespec`. > >     Standard behavior: Both POSIX and ISO C specifies them as such, > while all >     Windows APIs take relative durations as a 32-bit integer of > milliseconds, >     which can also easily get overflown. This also may be supported in existing threading models. Overflow is trivial to fix by waiting in a loop. (There are other reasons why OS support for absolute timeout is slightly better, but the price of this design decision makes it questionable. I plan to elaborate more on that on mingw ML, but I need to find time to do a bit of research first). Jacek