Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Implement mechanism to wait on any of several futexes

lkml.org

Post reply on HN
Print view View original

71–80 of 158 posts

Re: Implement mechanism to wait on any of several futexes

#71

Post by Shorel »

gnufied wrote: post #46

Personally for me - the problematic part of gaming on Linux has been input(i.e mouse) latency and acceleration profile. I am not sure if this is just my experience but when using libinput on Fedora for example - the cursor movement is not exactly precise. This is not obvious when working but while gaming this is a deal breaker.

Games in Windows can get raw mouse input just by writing the code for it, and Linux games usually don't because that would require root permissions, to add the user to the input group, etc.

It is a security issue and an X-Window design issue.

Re: Implement mechanism to wait on any of several futexes

#72

Post by Shorel »

mabbo wrote: post #32

Linux Gaming with Steam is actually quite nice these days. I spent about 3 years using an Ubuntu desktop for all my gaming at home. Most of the games I played installed via steam and worked great on Linux. The only reason I switched back to a Windows Desktop was that there were just one or two games I specifically wanted to try, but couldn't install to Linux. And once I had switched back (and paid the price for Windo…

> there were no games that needed Linux

That will never happen. You game in Linux because you need Linux first and games second.

Re: Implement mechanism to wait on any of several futexes

#73

Post by kbenson »

rbanffy wrote: post #23
ufo wrote: post #20

Earlier quoted context omitted.

Valve's post suggests that they believe this to be the case, although they didn't explain the specific details. > We think that if this feature (or an equivalent) was adopted upstream, we would achieve efficiency gains by adopting it in native massively-threaded applications such as Steam and the Source 2 engine.

I got that. I intended to go for "actually useful".

Source 2 has a linux port I believe, and it's an engine that other games could (do?) use to get easy linux support for a lot of their codebase. I think that counts for actually useful.

Depending on what they mean by "massively-threaded", that might cover some other popular network applications that thread to handle requests, but I'm not sure how much work they would put into a linux specific solution if it complicated their codebase.

Re: Implement mechanism to wait on any of several futexes

#74

Post by wbl »

Asooka wrote: post #62

I know the patch mentions interactive multimedia applications (games) in particular, but an actual mechanism to implement WaitForMultipleObjects on Linux would be very welcome for many high-performance multi-threaded applications. Say you have one worker thread per CPU core. On Windows, each thread would get an Event object and you would WaitOnMultiple to be able to act on the first unit of work that was complete. On…

On Linux your workers would push the work onto a single output queue or could signal and condition variable pointed to by the work. I've never really felt the need for WaitForMultiple.

Re: Implement mechanism to wait on any of several futexes

#75

Post by pizlonator »

swiley wrote: post #29

This looks to me like the main change is to make it easier to create mutexes with timeouts. Isn’t a mutex timing out an indication that: a) a lock wasn’t needed in the first place or b) the program is incorrect? It feels more like they just want the api to match win32 better but most of the multithreaded programming I’ve done lately has just used go’s channels so I totally could be missing something.

Its much more than timeouts. Here’s the killer use case outside wine:

- program with fine grained locks

- you have an algorithm that needs to acquire N of those locks, one at a time, and can do it in any order

In that case, you really want to:

- first attempt fast path locking on all of them in any order

- if that fails tell the kernel about all of the locks you are waiting on at once.

This means that you will become unblocked as soon as any lock becomes available.

That will make your program run faster. Therefore, it’s a good improvement for futexes in my opinion.

Re: Implement mechanism to wait on any of several futexes

#76

Post by pjc50 »

pizlonator wrote: post #75
swiley wrote: post #29

This looks to me like the main change is to make it easier to create mutexes with timeouts. Isn’t a mutex timing out an indication that: a) a lock wasn’t needed in the first place or b) the program is incorrect? It feels more like they just want the api to match win32 better but most of the multithreaded programming I’ve done lately has just used go’s channels so I totally could be missing something.

Its much more than timeouts. Here’s the killer use case outside wine: - program with fine grained locks - you have an algorithm that needs to acquire N of those locks, one at a time, and can do it in any order In that case, you really want to: - first attempt fast path locking on all of them in any order - if that fails tell the kernel about all of the locks you are waiting on at once. This means that you will become…

You can't acquire locks in any order, that's a recipe for deadlock when one process has acquired half the locks and another has the different half, resulting in them waiting on each other.

Use of WaitForMultipleObjects is more usually for completion of tasks, in the way that win32 "overlapped" works.

Re: Implement mechanism to wait on any of several futexes

#77

Post by oliwarner »

TrueDuality wrote: post #65
adrianmonk wrote: post #61

Earlier quoted context omitted.

Seems like in an ideal world, games would select that profile programmatically. Assuming, of course, that there's no reason to prefer mouse acceleration and that we're talking about using the mouse as a linear controller for stuff like aiming or moving.

Ideally yes, but remember that a lot of these games aren't designed for Linux but are effectively running in a compatibility layer for Windows. There is no way for the programmers to know that they need to be interacting with a Linux window manager's behavior.

Sounds like something for Feral's gamemode utility.

Re: Implement mechanism to wait on any of several futexes

#78

Post by lostmsu »

bityard wrote: post #49
Sahhaese wrote: post #16

Earlier quoted context omitted.

Depressing to see reviewers waste review bandwidth bringing up issues such as "wasted newline" and "incorrect comment format". Do kernel developers not use auto-formatters?

It's the same reason you dress nice and comb your hair for a job interview. If the developer of the patch couldn't get the easy minor details right before submitting, I wouldn't have much confidence that they spent a lot of effort thinking about the hard, major details either.

I think this is very backwards. When solving major problems details of taste are usually a blocker or waste of time.

Re: Implement mechanism to wait on any of several futexes

#79

Post by pizlonator »

pjc50 wrote: post #76
pizlonator wrote: post #75

Earlier quoted context omitted.

Its much more than timeouts. Here’s the killer use case outside wine: - program with fine grained locks - you have an algorithm that needs to acquire N of those locks, one at a time, and can do it in any order In that case, you really want to: - first attempt fast path locking on all of them in any order - if that fails tell the kernel about all of the locks you are waiting on at once. This means that you will become…

You can't acquire locks in any order, that's a recipe for deadlock when one process has acquired half the locks and another has the different half, resulting in them waiting on each other. Use of WaitForMultipleObjects is more usually for completion of tasks, in the way that win32 "overlapped" works.

You absolutely can try to acquire locks in any order if you are just trying to find the first one that is available.

Remember, the algorithm in my example is one where you hold locks one at a time. You can acquire locks in any order if you hold them one at a time.

Also my example is intentionally not about wine or win32. I’m articulating why this interface is independently valuable.

Re: Implement mechanism to wait on any of several futexes

#80

Post by jdsully »

I like how they won’t say the windows API’s name. WaitForMultipleObjects is quite nice - an epoll that works with all sorts of things not just fds. This is kind of a half assed implementation - sometimes I wish Linux would admit Windows has a good idea once in a while.
Post reply on HN