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

61–70 of 158 posts

Re: Implement mechanism to wait on any of several futexes

#61

Post by adrianmonk »

ilikehurdles wrote: post #55
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.

There is a "flat" profile that can be toggled in the Gnome Tweak Tool, assuming you're using Gnome in Fedora.

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.

Re: Implement mechanism to wait on any of several futexes

#62

Post by Asooka »

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 Linux you would have to roll your own solution using lower-level primitives and it will not be correct. Being able to wait on multiple events on Linux will be awesome.

Re: Implement mechanism to wait on any of several futexes

#63

Post by pjc50 »

wyldfire wrote: post #43
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.

It could be (b) -- it's incorrect because there's a deadlock due to incorrect mutex usage here. It could also be (c) -- it's correct but there's contention or: the mutex is too coarse / there's "too much" work being protected by the mutex. But I think your point about matching windows is likely the case (this is how wine implements WaitForMultipleObjects maybe?). The fd exhaustion with FUTEX_FD means they need anothe…

Yes, it looks exactly like WaitForMultipleObjects to me. A very reasonable plan. The mutexs aren't being used to exclude critical sections but as completion indicators for various tasks.

Re: Implement mechanism to wait on any of several futexes

#65

Post by TrueDuality »

adrianmonk wrote: post #61
ilikehurdles wrote: post #55

Earlier quoted context omitted.

There is a "flat" profile that can be toggled in the Gnome Tweak Tool, assuming you're using Gnome in Fedora.

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.

Re: Implement mechanism to wait on any of several futexes

#66

Post by badamp »

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…

Linux already has what you’re talking about with eventfd and epoll.

In Linux each thread can get an eventfd and you can POLLIN all of them.

In fact I would argue that using futexes is the “roll your own solution” using lower level primitives (and easier to fuckup) much more so than eventfd and epoll.

As mentioned somewhat poorly in the post, using futexes gives a performance boost which is not surprising since they are fast user mutexes. FWIW I didnt think windows events had a fast user space path but I may be mistaken.

For most worker pool scenarios you’re describing, the overhead of eventfd is probably in the noise.

Re: Implement mechanism to wait on any of several futexes

#67

Post by adrianmonk »

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.

Good point. I guess the emulator could request the profile, but then you either need a one-size-fits-all approach or somebody has to maintain a database of which games to enable it for.

Re: Implement mechanism to wait on any of several futexes

#68

Post by hinkley »

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.

Mutex timeouts show up in some implementations as leases.

Essentially you're putting a lower bound on Availability in favor of Consistency. Lease expiry happens when the lessor isn't around to retire the lease in an orderly fashion. It's detecting a Partition. In theory a network partition, but we all know how CPU boundedness creeps into the system as the feature set or the data set grows... and that can show up even on a solitary machine.

Re: Implement mechanism to wait on any of several futexes

#69

Post by smaddox »

AstralStorm wrote: post #52
Pfhreak wrote: post #36

Earlier quoted context omitted.

Correctness isn't always the right thing to do. Games, in particular, are full of code that approximates the right thing and falls back to less and less correct solutions. It's more important to be fast than right in a lot of cases. Dropping frames can have a significant negative experience for players. Dropping an AI pathing algorithm, particle physics computation, or other background task can often be fine or even…

Approximations, including temporal ones, are also science. Ever seen a texture pop in instead of a stutter? If a lock would be taken on that load without timeout (very short) it'd either not load on time or load when it's no longer needed.

No need for a lock for such synchronization between a loading thread and a rendering thread, though, when you can use an atomic pointer or ready flag.

Maybe a lazy GUI framework could use a mutex timout, though.

Re: Implement mechanism to wait on any of several futexes

#70

Post by peterzz »

db48x wrote: post #24
nixgeek wrote: post #22

Earlier quoted context omitted.

On the contrary, I think the feedback provided was excellent and far better than just saying “Doesn’t conform to our style guidelines, please try again”. Bravo Peter. This may be someone’s first submission and they may consequently not be aware of style guides, tools which can help lint, etc?

Agreed. Also "missing {}" is a super important "style" comment.

Because bugs due to missing {} happen, and are a royal pain, the rule is that any nontrivial statement; especially any multi-line; must have braces.

Also, given the amount of patches I have to read, uniform style really does matter. Unconventional style breaks the flow and detracts from the important bits.

Also, I'm not aware of a lint like tool that works on diffs. Many of the patches never get further than my MUA.

Post reply on HN