This is the mail archive of the
mailing list for the GCC project.
Re: Re: Adding a new thread model to GCC
- From: Torvald Riegel <triegel at redhat dot com>
- To: lh_mouse <lh_mouse at 126 dot com>
- Cc: gcc <gcc at gcc dot gnu dot org>, mingw-w64-public <mingw-w64-public at lists dot sourceforge dot net>
- Date: Thu, 14 Apr 2016 14:58:55 +0200
- Subject: Re: Re: Adding a new thread model to GCC
- Authentication-results: sourceware.org; auth=none
- References: <2f3897eb dot bbc0e dot 1540ee9aa0b dot Coremail dot lh_mouse at 126 dot com> <1460569249 dot 3869 dot 382 dot camel at localhost dot localdomain> <79ded40b dot be78c dot 1541295e77a dot Coremail dot lh_mouse at 126 dot com>
On Thu, 2016-04-14 at 10:24 +0800, lh_mouse wrote:
> Yes I learnt those *ByAddress* functions a few months ago and was shocked that Microsoft had plagiarized futex from Linux.
> As you have pointed out already, those APIs are only available on Windows 8 and later.
Yes. On Windows 8, given that we have futexes, I'd just use those. An
exception might be made if Windows offers native support for certain
datastructures such as rwlock or condvars.
The question that remains is what we then do for Vista and Win 7. What
you initially proposed is one option.
> If we need fuex semantics on Windows 7 and earlier, we must simulate it.
> However, since futexes and keyed events work differently, simulation of futexes using keyed events would:
> 0) require a lot of work, and
Are you sure about this? Unlike POSIX, we have no process-shared
concurrent data structures, so all you'd need for a futex implementation
would be to build wait queues. You need that anyway unless you don't
want to support std::synchronic (which is likely to become part of a TS
in the near future).
> 1) suffer from performance penalty just like if we simulate keyed events on Windows 2000.
Why would that be the case? Especially for WakeByAddressSingle, there's
not much you need to do compare to what you'd do for a mutex. Blocking
(ie, where you'd use a futex) is on the slow path anyway.
> The major difference is that, the FUTEX_WAIT syscall is an atomic compare-and-sleep operation, while the NtWaitForKeyedEvent syscall provides no comparison.
> Instead, the NtReleasedKeyedEvent syscall blocks the current thread until one thread is woken up, while FUTEX_WAKE does nothing and returns immediately.
Yeah, the emulation would need an explicit handshake.
> So here is my condition: in no event shall portability harm either efficiency or maintainability.
Maintainability is what the motivation behind what I proposed.
> Linux and Windows work differently. I consider it 'harmful' to make one look like the other.
Hey, at the latest once we end up in C++, they do look the same! So all
we're discussing here is at which level we're unifying. I'm not asking
you to emulate POSIX or syscalls.