Linux Kernel patch sent in for comments to help gaming

Does that mean there's no such thing as WaitMultipleObjects on Linux? How would a Linux programmer solve that?

Does that mean there's no such thing as WaitMultipleObjects on Linux? How would a Linux programmer solve that?

My first thought, with no specific knowledge of the details, is that you would use a single event for all the possible sources and pass a parameter to indicate which. For system events, or a non-controlled application, probably set up multiple threads that wait each for a different event and then wakes up the thread you actually want.

But this is, of course, assuming that you are just adapting an existing code. When developing for Linux directly, people would just use a different algorithm that didn't rely on that; I don't think this is a particularly fundamental feature for multi-threaded development.

Does that mean there's no such thing as WaitMultipleObjects on Linux? How would a Linux programmer solve that?

$ man poll
$ man select
That's your answer.

I don't know what is the issue with wine, but I guess that their problem may be related to fd (but is mentioned as secondary improvement, so I'm not sure...)

Does that mean there's no such thing as WaitMultipleObjects on Linux? How would a Linux programmer solve that?

$ man poll
$ man select
That's your answer.

I don't know what is the issue with wine, but I guess that their problem may be related to fd (but is mentioned as secondary improvement, so I'm not sure...)

And more recently, epoll. I don't know what their problem with fds are, but everything being an fd is the best thing to have happened to unix. Things that weren't an fd turned out to be the most problematic (pid, signals), and they are turning into fds in recent Linuxes too.

Maybe they can get windows-y programs to run faster with windows-y kernel features, but I certainly hope no one would use this feature outside wine.

$ man poll
$ man select
```
That's your answer.

I don't know what is the issue with wine, but I guess that their problem may be related to fd (but is mentioned as secondary improvement, so I'm not sure...)

And more recently, epoll. I don't know what their problem with fds are, but everything being an fd is the best thing to have happened to unix. Things that weren't an fd turned out to be the most problematic (pid, signals), and they are turning into fds in recent Linuxes too.

Maybe they can get windows-y programs to run faster with windows-y kernel features, but I certainly hope no one would use this feature outside wine.

I guess that somewhat answers the question I would have asked:
Poll and select seem to be all about files, while...

The WaitForMultipleObjects function can specify handles of any of the following object types in the lpHandles array:

Change notification
Console input
Event
Memory resource notification
Mutex
Process
Semaphore
Thread
Waitable timer

This still sounds useful to me.

And more recently, epoll. I don't know what their problem with fds are, but everything being an fd is the best thing to have happened to unix. Things that weren't an fd turned out to be the most problematic (pid, signals), and they are turning into fds in recent Linuxes too.

Maybe they can get windows-y programs to run faster with windows-y kernel features, but I certainly hope no one would use this feature outside wine.

There is no way to use fds for synchronization without a syscall. That's no good for performance-critical paths. Pthreads primitives like mutex, condition, semaphore are designed to avoid syscalls where possible. Ideally (e.g. uncontended mutex lock) they use only atomic operations, but they call futex when they need to block, or to wake other threads.

Being able to wait on multiple futexes at once seems generally useful to me.

Linux supports waiting multiple objects, but only if they're backed by file descriptors, the problem with sincronization primitives is they frequently aren't, as a developer specialized on parallelism and distributed processing getting something like this mainlined would make me quite happy.

When i wanted to implement my own threading API on linux a few years ago, i found out that there were no system procedure to pause or resume a thread from another thread unlike Windows. You had to use signals for that and it was really messy.

When i wanted to implement my own threading API on linux a few years ago, i found out that there were no system procedure to pause or resume a thread from another thread unlike Windows. You had to use signals for that and it was really messy.

Suspending threads comes with so many caveats that on platforms there they do exits (i.e Windows) they are marked as not to be used by anything other than debuggers really, and you are instead referred to use the same kinds of thread to thread syncronization that you have on i.e Linux such as e.g condition variables.

$ man poll
$ man select
```
That's your answer.

I don't know what is the issue with wine, but I guess that their problem may be related to fd (but is mentioned as secondary improvement, so I'm not sure...)

And more recently, epoll. I don't know what their problem with fds are, but everything being an fd is the best thing to have happened to unix. Things that weren't an fd turned out to be the most problematic (pid, signals), and they are turning into fds in recent Linuxes too.

Maybe they can get windows-y programs to run faster with windows-y kernel features, but I certainly hope no one would use this feature outside wine.

I guess that somewhat answers the question I would have asked:
Poll and select seem to be all about files, while...

The WaitForMultipleObjects function can specify handles of any of the following object types in the lpHandles array:

Change notification
Console input
Event
Memory resource notification
Mutex
Process
Semaphore
Thread
Waitable timer

This still sounds useful to me.

And out of that list it's mostly mutexes and semaphores where Linux is lacking (most of the others on that list have an equivalent and thus can be used with epoll). And being able to wait for a mutex or a semaphore with epoll would have been a very nice addition, BSD have kqueue where you can wait for both fd:s, signals and mutex/semaphores with the same function and it existed before epoll so quite a large number of people are upset that Linux went with their own API that had less functionality (that said I do prefer the API of epoll over kqueue, just the functionality that is lacking).

In the end it just means that you as a Linux developer write your application in a different way than what you would have done on Windows or BSD so the major problem comes with things like WINE since they have to support the WIN32 interface.

edit: It also have to be said that this patch does not solve the "listen to both fd:s and other stuff with the same interface" since it just implements a way to listen to several FUTEX:es at the same time.


Last edited by F.Ultra on 14 June 2020 at 2:56 pm UTC

There is no way to use fds for synchronization without a syscall. That's no good for performance-critical paths. Pthreads primitives like mutex, condition, semaphore are designed to avoid syscalls where possible. Ideally (e.g. uncontended mutex lock) they use only atomic operations, but they call futex when they need to block, or to wake other threads.

Being able to wait on multiple futexes at once seems generally useful to me.

Do you know of a common concurrency problem were it makes sense? For me it sounds like a developer is trying to outsmart the scheduler due to a bad soft design and that will always end bad.

Not long ago there was a google engineer that published some code where he implemented spinlocks in order to "improve" performance (basically a busy waiting code to avoid doing the syscall), but in his numbers std::mutex proved to be a good solution on Linux but a "bad one" on Windows. So the issue here was they are Windows programmers that decided to program a Windows workaround on Linux when it's not necessary... IMO this is a prove of why you want to keep at bare minimum threads priority setup on programmers side.

My non-coder, non-developer takeaway is 'Game go faster, this good. Make good thing. Make game go faster." :)

There is no way to use fds for synchronization without a syscall. That's no good for performance-critical paths.

It is possible to build a fast-pathed mutex (and condition variable) that is userspace only and falls backs on a eventfd for the slow path, exactly like for futex based mutexes [1]. In fact because they do not have to fiddle with VM stuff, I have seen claims that eventfds can be slightly faster on the slow path (but nobody really cares about that, so keep using futexes unless you need to interoperate with poll and friends).

The advantage of futexes is that they are ephemeral and the kernel side support data structures are allocated implicitly on a futex_wait call (when a futex is used to wait for an event) and destroyed as soon as there are no waiters, while eventfds are allocated and destroyed explicitly. But you can have millions of inactive futexes without any issues, while with eventfd you can hit the fd limit very easily. Apparently there are a lot of broken programs that allocate and leak Windows mutex handlers (which are pretty much the equivalent of an Unix fd) but probably because Windows has code to workaround this brokenness or because handlers are lighter weights, it is not much of an issue there. Note that Windows today has keyed events (which are exactly like futexes) and those can't be used on WaitForMultipeObjects either.


[1] I know because I have done it.

as a dev doing low level multithreaded stuff from time to time, this change also enables 64 bit futexes which is quite useful. Linus pushed back on them in the past for questionable reasons, but Windows has them so, any fast emulation in Wine will probably need them as well.