5 ms·

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 ef

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.

CyberDildonics 6mo ago
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.
- Dylan16807 6mo ago
  > 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.
  - CyberDildonics 6mo ago
    You gave a perfectly good answer to the half a sentence you quoted, Good, because that's what I meant to do, which is why that's what I quoted.
    - Dylan16807 6mo ago
      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???
      - CyberDildonics 6mo ago
        They asked how often an ipc lock would be used in games and I answered. why did you argue with me??? You replied to me.
        Dylan16807 6mo ago
        > 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.
        CyberDildonics 6mo ago
        You did not answer the question they asked. 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. The way you argued implies you weren't doing that on purpose, and thought you were answering their actual question. No, that's not true, I think you made all that up.
        6mo ago

CyberDildonics 6mo ago

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.

Dylan16807 6mo ago
> 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.
- CyberDildonics 6mo ago
  You gave a perfectly good answer to the half a sentence you quoted, Good, because that's what I meant to do, which is why that's what I quoted.
  - Dylan16807 6mo ago
    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???
    - CyberDildonics 6mo ago
      They asked how often an ipc lock would be used in games and I answered. why did you argue with me??? You replied to me.
      - Dylan16807 6mo ago
        > 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.
        CyberDildonics 6mo ago
        You did not answer the question they asked. 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. The way you argued implies you weren't doing that on purpose, and thought you were answering their actual question. No, that's not true, I think you made all that up.
        6mo ago