This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Re: Adding a new thread model to GCC

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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]