3 ms·

Are you really going to put while(true) around every nearly every access of mutable state in your programs? That is the implication I get from your comment. I r

Are you really going to put while(true) around every nearly every access of mutable state in your programs? That is the implication I get from your comment. I really think you should think hard before trying to dig your way out of a hole like that.

Dylan16807 3y ago
It's not very different from grabbing a mutex on the string. Except that someone is more likely to hang a mutex forever than to make this code hang forever. So yes that's fine. Why wouldn't it be? And "every time a string is copied" is pretty far from "nearly every access of mutable state". Also unless the string-changing code has a very elaborate timing attack, won't it only make the constructor loop again about half the time at most?
- dundarious 3y ago
  This thread is honestly crazy to me. I've never seen so many people advocate for hot spin loops as a patchwork attempted solution to data races. Never mind have I never seen this recommended in any serious literature, I've never even seen it suggested in a random blog post, or in the worst code bases I've ever worked with (I have worked on some not great code in my professional experience in the past). And the reason I am talking about mutable state, is because these issues are not specific to strings! Why do you think there's something special about these kinds of data races that make them specific to strings? I really, genuinely hope you take some time to read more deeply into this topic, and talk with your peers about this some more, before you implement any of these ideas. The fundamental lesson I think is that data races must be eliminated, and there is no solution that tolerates them or works around them. You must eliminate them from your code. A key related lesson is that there is no unilateral way to do this for shared mutable state. If there is shared mutable state, 2 or more concurrent threads must co-operate in order to avoid data races (all threads must lock, or use atomics, or fences, etc.). "There is no unilateral solution", means there is no way to loop or lock or fence in just one thread, in order to fix or resolve or work around some other thread that does not.
  - Dylan16807 3y ago
    I didn't advocate it. I said the deadlock risk is not meaningful. You're badly misreading me.
    - dundarious 3y ago
      I'm genuinely glad you're not advocating for it. If your reasoning for that is not the same as mine, I hope it's equally critical.

Dylan16807 3y ago

It's not very different from grabbing a mutex on the string. Except that someone is more likely to hang a mutex forever than to make this code hang forever. So yes that's fine. Why wouldn't it be? And "every time a string is copied" is pretty far from "nearly every access of mutable state". Also unless the string-changing code has a very elaborate timing attack, won't it only make the constructor loop again about half the time at most?

dundarious 3y ago
This thread is honestly crazy to me. I've never seen so many people advocate for hot spin loops as a patchwork attempted solution to data races. Never mind have I never seen this recommended in any serious literature, I've never even seen it suggested in a random blog post, or in the worst code bases I've ever worked with (I have worked on some not great code in my professional experience in the past). And the reason I am talking about mutable state, is because these issues are not specific to strings! Why do you think there's something special about these kinds of data races that make them specific to strings? I really, genuinely hope you take some time to read more deeply into this topic, and talk with your peers about this some more, before you implement any of these ideas. The fundamental lesson I think is that data races must be eliminated, and there is no solution that tolerates them or works around them. You must eliminate them from your code. A key related lesson is that there is no unilateral way to do this for shared mutable state. If there is shared mutable state, 2 or more concurrent threads must co-operate in order to avoid data races (all threads must lock, or use atomics, or fences, etc.). "There is no unilateral solution", means there is no way to loop or lock or fence in just one thread, in order to fix or resolve or work around some other thread that does not.
- Dylan16807 3y ago
  I didn't advocate it. I said the deadlock risk is not meaningful. You're badly misreading me.
  - dundarious 3y ago
    I'm genuinely glad you're not advocating for it. If your reasoning for that is not the same as mine, I hope it's equally critical.