From: LIU Hao <lh_mouse@126.com>
To: i.nixman@autistici.org, Jonathan Wakely <jwakely@redhat.com>
Cc: libstdc++@gcc.gnu.org, gcc-patches@gcc.gnu.org,
Eric Botcazou <ebotcazou@adacore.com>
Subject: Re: Adding a new thread model to GCC
Date: Fri, 21 Oct 2022 19:36:23 +0800 [thread overview]
Message-ID: <3d80a59c-39f4-85e0-3558-062ddcd5ece7@126.com> (raw)
In-Reply-To: <7277b1d9a835d8cc651ab112eac8c2e7@autistici.org>
[-- Attachment #1.1: Type: text/plain, Size: 3867 bytes --]
在 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.
[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
--
Best regards,
LIU Hao
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]
next prev parent reply other threads:[~2022-10-21 11:36 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-01 18:34 LIU Hao
2022-10-01 20:02 ` Bernhard Reutner-Fischer
2022-10-21 9:58 ` Jonathan Wakely
2022-10-21 10:09 ` i.nixman
2022-10-21 10:48 ` Jonathan Wakely
2022-10-21 10:55 ` i.nixman
2022-10-21 11:36 ` LIU Hao [this message]
2022-10-21 11:54 ` i.nixman
2022-10-21 12:19 ` LIU Hao
2022-10-21 12:34 ` i.nixman
2022-10-24 3:40 ` LIU Hao
2022-10-24 20:50 ` Jacek Caban
2022-10-21 11:44 ` Eric Botcazou
2022-10-21 11:55 ` i.nixman
2022-10-24 6:53 ` i.nixman
2022-10-24 8:15 ` Eric Botcazou
2022-10-24 8:20 ` i.nixman
2022-10-31 9:18 ` Eric Botcazou
2022-10-31 15:22 ` i.nixman
2022-11-01 5:22 ` i.nixman
2022-11-01 9:09 ` Eric Botcazou
2022-11-02 12:05 ` i.nixman
2022-11-02 21:27 ` Eric Botcazou
2022-11-02 21:40 ` i.nixman
2022-12-16 17:18 ` Jonathan Wakely
2022-12-16 19:20 ` Eric Botcazou
2022-12-22 12:21 ` Jonathan Yong
2022-12-22 12:28 ` i.nixman
2022-12-23 23:59 ` Jonathan Yong
2022-12-24 5:58 ` NightStrike
2022-12-24 6:27 ` i.nixman
2022-12-24 13:50 ` i.nixman
2022-12-24 15:42 ` i.nixman
2022-12-24 15:57 ` i.nixman
2022-12-24 21:22 ` i.nixman
2022-12-25 1:10 ` Jonathan Yong
2023-01-09 21:56 ` Eric Botcazou
2022-12-24 6:22 ` i.nixman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3d80a59c-39f4-85e0-3558-062ddcd5ece7@126.com \
--to=lh_mouse@126.com \
--cc=ebotcazou@adacore.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=i.nixman@autistici.org \
--cc=jwakely@redhat.com \
--cc=libstdc++@gcc.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).