From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from devianza.investici.org (devianza.investici.org [198.167.222.108]) by sourceware.org (Postfix) with ESMTPS id 5E3323856974; Fri, 21 Oct 2022 11:54:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 5E3323856974 Authentication-Results: sourceware.org; dmarc=pass (p=reject dis=none) header.from=autistici.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=autistici.org Received: from 1.mail-backend.investici.org (unknown [10.0.0.11]) by devianza.investici.org (Postfix) with ESMTP id 4Mv2tw5pQCz6vMg; Fri, 21 Oct 2022 11:54:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=autistici.org; s=stigmate; t=1666353256; bh=wlfnyAv2SAid+exHkAi4XchOKlUSAugl2Sj2WPgzK0w=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=o7w2tgJ7t/LQck127rHea+GEgNerpQo4HD4Rei5DBw9F6iQzkdBS5bO5fevYdkguR T8W7+caRZO5UchorfPnRVubgiXyh5z3mctY9Iq2267CJEpBkg7YtJxzzAHo0udsvGB rZIoxXXoGQd/4dVXA0RYdQPvERC6Doo9mfOGTWQg= Received: from 1.webmail.investici.org (localhost [127.0.0.1]) (Authenticated sender: i.nixman@autistici.org) by 1.mail-backend.investici.org (Postfix) with ESMTPA id 4Mv2tw4fBFz5sjW; Fri, 21 Oct 2022 11:54:16 +0000 (UTC) MIME-Version: 1.0 Date: Fri, 21 Oct 2022 11:54:16 +0000 From: i.nixman@autistici.org To: LIU Hao Cc: Jonathan Wakely , libstdc++@gcc.gnu.org, gcc-patches@gcc.gnu.org, Eric Botcazou Subject: Re: Adding a new thread model to GCC In-Reply-To: <3d80a59c-39f4-85e0-3558-062ddcd5ece7@126.com> References: <0f1f223a-3756-1da3-bd1d-b87edd34e1f9@126.com> <7277b1d9a835d8cc651ab112eac8c2e7@autistici.org> <3d80a59c-39f4-85e0-3558-062ddcd5ece7@126.com> User-Agent: Roundcube Webmail Message-ID: X-Sender: i.nixman@autistici.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_SHORT,RCVD_IN_DNSWL_NONE,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 2022-10-21 11:36, LIU Hao wrote: > 在 2022/10/21 18:09, i.nixman@autistici.org 写道: >> On 2022-10-21 09:58, Jonathan Wakely via Libstdc++ wrote: >>> How does this compare with Eric B's proposal at >>> https://gcc.gnu.org/legacy-ml/gcc-patches/2019-06/msg01840.html ? >>> >>> It would be good if we can accept one of them for GCC 13, but I don't >>> know Windows well enough to determine which is better. >> >> I had the same question... >> I would like to understand what is the difference? >> Moreover I would like to understand what is the difference with the >> already added support for the winpthreads library? >> >> @LIU Hao, could you explain please? >> >> >> > > Thank you for your interest. I'm glad to make an introduction of it. > > > I have read this patch before. Let's take the mutex as an example: > > There are a lot of ways to implement a mutex on Windows. Basically, a > non-recursive mutex can be implemented with an atomic counter + a > binary semaphore / auto-reset event. This proposed patch contains a > `__gthr_win32_CRITICAL_SECTION` definition that I think is a duplicate > of the internal `CRITICAL_SECTION` structure, so should also work the > same way as it. > > The problem about this approach is that, semaphores are valuable > kernel objects, and the maximum number of HANDLEs that a process can > open concurrently has a limit (like FDs on Linux), while 'many > critical sections are used only occasionally (or never at all), > meaning the auto-reset event often isn’t even necessary' [1], the > semaphores are actually allocated on demand. This means that locking > can fail. There is a story in article [1] which also explains the > origination of keyed events; it's worth reading. > > And, since Vista we also have native win32 condition variables, also > implemented basing on keyed events. > > > The keyed events are undocumented and are only exposed via syscalls. > However, as with other documented syscalls, available from Windows > Drivers Kit, there are several advantages: > > * There is a global keyed event, which requires no initialization, > but > can be utilized by all processes. Basing on that, mcfgthread > provides > mutexs, condition variables, once flags, etc. that are all > one-pointer > size structs, consume absolutely no additional resource, allow > constexpr initialization, and require no cleanup, much like on > Linux. > > * The wait syscalls take a 64-bit integer, whose positive value > denotes > the number of 10^-7 seconds since 1600-01-01 00:00:00 Z, and whose > negative value denotes a relative timeout. Hence it's much more > simpler > to implement `__gthread_mutex_timedlock()` and > `__gthread_cond_wait()` > which take absolute timeouts. On the other hand, Win32 APIs > generally > take a 32-bit relative timeout in milliseconds, which not only > requires > translation from an absolute timepoint argument, but can also > easily > get overflown. > > * Building mutexes on top of syscalls allows a better designed > algorithm > [2], and sometimes it can even outperform native `SRWLOCK`s [3]. > > * mcfgthread also provides standard-conforming `__cxa_atexit()` and > `__cxa_thread_atexit()` functions, for working around some strange, > weird, and broken behaviors [4][5][6]. On Linux it's glibc that > provides them, so this as a whole requires a little modification in > mingw-w64. I am working on it however; hopefully we can land it > soon. > > thank you LIU Hao for the explanation! I have a questions: 1) wouldn't it be logical not to write yet another implementation of pthreads-wor-windows, but to make changes to the winpthreads library because it's already supported by GCC? (maybe I don’t know about some reasons why it wasn’t done ...) It seems to me the ideal and logical option is to make your implementation part of GCC, as suggested by Eric B. the advantages are as follows: 1) we will get a high-quality native implementation. 2) there is no need to add another thread model for GCC. 3) with dynamic linking there is no need to ship another dll with the program. (Windows users really don't like this =)) best! > [1] > http://joeduffyblog.com/2006/11/28/windows-keyed-events-critical-sections-and-new-vista-synchronization-features/ > > [2] https://github.com/lhmouse/mcfgthread/blob/master/MUTEX.md > [3] https://github.com/lhmouse/mcfgthread#benchmarking > > [4] https://sourceforge.net/p/mingw-w64/mailman/message/37268447/ > [5] https://reviews.llvm.org/D102944 > [6] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80816