Comment by wtallis
17 hours ago
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.)
It very often being used for thread management inside single process etc. Very convenient. Nobody says it has to be default.
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.
3 replies →