I developed for windows before moving to linux. I was surprised to find that was no system call similar to windows WaitForMultipleObjects. Sure you can implement something similar using poll() or using condition variables. but WaitForMultipleObjects seems so much simpler and more versatile
The article mentions this: "A few years back, Linux added a way for software to wait on several events at once, which is something Windows had built in for decades, but Linux didn't."
The last time I asked the same question here, user dwattttt finally pointed out[1][2] to me that there is a significant difference: wfmo can actually acquire semaphores in addition to waiting for them, which poll can't do in a non-racy way and efficient way. It can also do rendezvous synchronization (i.e. signal-and-wait).
A lot of that flexibility is what makes it hard to efficiently emulate (especially without kernel level support), but some of it seems too flexible to make sense as the default choice. How often does a video game really need a lock that can be shared between processes, and why should that lock type be the one that a game engine uses for almost all of its locks?
> How often does a video game really need a lock that can be shared between processes,
What do you mean? SRWLock (or the older CRITICAL_SECTION) cannot be shared between processes. A (Win32) Mutex does work across processes, but that's its entire purpose. So Windows does have different tools for different jobs.
In fact, it's really the other way round: on Linux, a futex also works across processes, but there is no equivalent in Windows. (Sadly, WaitOnAddress can only be used in a single process.)
How often does a video game really need a lock that can be shared between processes,
That seems hugely useful for interprocess communication and I can immediately think of reasons to use IPC in a game. Having a separate voice process for one.
But that goes back to "how often". Not how many games use it, but how many times per second they use it. You might touch your voice process lock once per frame? That's negligible in terms of CPU time. Any half-reasonable overhead makes no difference in that lock, but might have a big impact in a more common lock.
It absolutely can make a difference because if you have locks that are supposed to sync or wake up other processes you care about latency not cpu usage.
What specifically are you saying can make a difference?
I'm saying that extra overhead from making your lock work across processes should be very tiny. That overhead shouldn't add much more than a microsecond in either latency or CPU usage, compared to an in-process lock.
You were saying "reasonable overhead" makes no difference because something "isn't called much". This is not only ambiguous but also not true because latency is important.
What calls specifically are you talking about between windows and linux? This was started by someone talking about WaitForMultipleObjects.
I wasn't excusing all overhead, I was excusing the difference in overhead caused by making the lock more flexible. Because that's what the discussion is about, a lock that can be shared between processes versus a lock that can't be. The penalty for being "too flexible".
But assuming reasonable implementations, the difference between those two lock styles shouldn't be more than about a microsecond, should it? So that's fine for a lock that's only used 100 times a second.
I was excusing the difference in overhead caused by making the lock more flexible
What are the two functions you're comparing and what is the actual difference in overhead that you're talking about?
a lock that can be shared between processes versus a lock that can't be.
This is a dramatic black and white difference, these would be used for two different things. In that case it's apple and oranges, one would be for interprocess communication and one wouldn't.
the difference between those two lock styles shouldn't be more than about a microsecond,
What are you basing this on? Do you have an examples or benchmarks of the actual calls and their timings?
fine for a lock that's only used 100 times a second.
Again, latency isn't about how many times something is called per second. That would matter for throughput.
> In that case it's apple and oranges, one would be for interprocess communication and one wouldn't.
The whole point of the complaint was wtallis claiming the inter-process-capable lock was being used for locks that don't need it! That's the foundation of this conversation!
> What are you basing this on?
Basic coding knowledge and an assumption of competency. There's no good reason for it to slow down more than that when it's used the same way. If you have a reason go ahead and tell me.
> Again, latency isn't about how many times something is called per second. That would matter for throughput.
I addressed both.
The extra latency for using an overly capable lock should be negligible. That's not the problem anyone is worried about.
Basic coding knowledge and an assumption of competency.
This is just saying "I just know", but what specific function and basic timings are you going off of? If you don't know, why are you so sure of the numbers?
The whole point of the complaint was wtallis claiming the inter-process-capable lock was being used for locks that don't need it! That's the foundation of this conversation!
They were saying it's rare to need IPC lock for video games and I don't think that's true, then I gave a scenario where you would use one.
If you're not actually using it between processes, the overhead could be as small as an extra conditional. For an upper bound I think a couple wasted syscalls makes sense. Why would it be significantly slower than that?
But whatever, let's focus on the actual point:
> They were saying it's rare to need IPC lock for video games and I don't think that's true, then I gave a scenario where you would use one.
And I was pointing out that a voice IPC lock is still "rare" when we use the most appropriate definition of "rare" for this context. In this context of worrying that using the wrong kind of lock will slow the game down, how often we're using the lock matters. If we go 50 million CPU cycles between uses, it's "rare".
The post you originally responded to was comparing the general idea of locks that can work between processes and ones that can't. And it was criticizing the efficiency of the former, which is a measure of throughput.
There's no reason for an upgraded lock to significantly change in latency. That's not what they were worried about when criticizing the idea of using the former lock as the main lock type in a game. Your most used locks need throughput.
So no, latency is not what matters. And I've explained why I say that in multiple ways, while you haven't given any explanation for why you're focusing on latency.
When they asked "how often" in the middle of that criticism, they're not looking for an example that sprinkles in a couple calls, they're looking for something that puts serious load onto the lock. Any answer that is once per frame or less is not properly addressing the question.
So no, latency is not what matters. And I've explained why I say that in multiple ways,
No you haven't, you keep talking about doing something 100 times, but if you have a lock between processes, getting those processes to wake up and know the unlock happened with low latency is what matters. After the unlock whatever happens is going to be fast anyway, which in IPC is probably going to be copying memory.
What specific function call are you thinking of that would have high overhead but not latency and the latency wouldn't matter?
you originally responded to
I replied to someone saying "how often do you use a shared lock in games" and I said there are obvious uses.
> No you haven't, you keep talking about doing something 100 times
That has not been part of all my explanations. But just so I can make it as clear as possible I will now explain it again without mentioning how many times it's called anywhere in the rest of my comment:
> if you have a lock between processes, getting those processes to wake up and know the unlock happened with low latency is what matters
Whether it matters depends on what you're benchmarking.
When the alternative to IPC is waking up another thread, your latency should be about the same either way. It's not what they were trying to compare.
The core comparison they wanted to make was about the simplicity of using a single lock type versus the overhead of using an IPC-capable lock everywhere. A better way to phrase their actual question is about how deep those IPC needs go in contrast to their downsides, not just whether there's a single call site somewhere.
> I replied to someone saying "how often do you use a shared lock in games" and I said there are obvious uses.
You gave a perfectly good answer to the half a sentence you quoted, if that half sentence was in a vacuum. But it was not in a vacuum, and your answer was not good for what they were actually asking.
And so my first comment clarified that you didn't answer the question. But if answering just that half sentence was on purpose, why did you argue with me???
> They asked how often an ipc lock would be used in games and I answered.
You did not answer the question they asked. You answered what would have been a reasonable interpretation of half of their sentence, if there hadn't been more text directly around it.
> You replied to me.
I did.
But if you were purposefully isolating half their sentence, there was no reason for you to argue with that reply. The way you argued implies you weren't doing that on purpose, and thought you were answering their actual question.
> They did ask it because I quoted it and replied. That's how these forums work. People write text and other people reply to it.
No, you quoted half a sentence. That wasn't the whole question. You didn't answer the actual question.
The fact that you're still insisting you answered the question makes it clear why you argued with me when I was just clarifying things. You didn't answer something different on purpose, you're still stubbornly acting like you answered the right thing.
You did not answer their actual question. Period. I'm leaving now.
