4 ms·

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 need

by swiley 7y ago

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.

pizlonator 7y ago
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.
- pjc50 7y ago
  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.
  - pizlonator 7y ago
    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.
  - deleted 7y ago
    [deleted]
zamalek 7y ago
One valid scenario for mutexes timing out is stealing: 1. Each CPU first attempts to take an allocated object from its own pool, using a 1ms timeout to acquire the mutex on the pool. 2. If that fails, the CPU attempts to steal from the other CPU pools, using a zero timeout (immediately return if the mutex can't be taken). 3. If that fails, acquire the mutex on its own pool with an infinite timeout. This is definitely correct and is much faster than any of the lock-free approaches I could come up with. I guess the general class of problems where mutex timeouts help is when you have "many valid options, some of which are being used by others."
- swiley 7y ago
  That totally makes sense, thanks for correcting me. :)
Pfhreak 7y ago
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 unnoticed.
- AstralStorm 7y ago
  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.
  - smaddox 7y ago
    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.
wyldfire 7y ago
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 another way.
- pjc50 7y ago
  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.
hinkley 7y ago
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.

by swiley 7y ago

pizlonator 7y ago

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.

pjc50 7y ago
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.
- pizlonator 7y ago
  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.
- deleted 7y ago
  [deleted]

zamalek 7y ago

One valid scenario for mutexes timing out is stealing: 1. Each CPU first attempts to take an allocated object from its own pool, using a 1ms timeout to acquire the mutex on the pool. 2. If that fails, the CPU attempts to steal from the other CPU pools, using a zero timeout (immediately return if the mutex can't be taken). 3. If that fails, acquire the mutex on its own pool with an infinite timeout. This is definitely correct and is much faster than any of the lock-free approaches I could come up with. I guess the general class of problems where mutex timeouts help is when you have "many valid options, some of which are being used by others."

swiley 7y ago
That totally makes sense, thanks for correcting me. :)

Pfhreak 7y ago

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 unnoticed.

AstralStorm 7y ago
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.
- smaddox 7y ago
  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.

wyldfire 7y ago

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 another way.

pjc50 7y ago
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.

hinkley 7y ago

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.