3 ms·
> a way of writing code where "might this crash?" is a question you're never bothered to ask. Is that actually true? Yes, you won't get a partially written int
by wtetzner 11y ago
> a way of writing code where "might this crash?" is a question you're never bothered to ask.
Is that actually true? Yes, you won't get a partially written int, but you could still run into consistency issues if you don't lock. For example, if you need thread A to update both x and y to have a consistent state, and B is reading both x and y, A might update x, then the scheduler would switch to B, and be might read the new x and the old y. If the update A was making needed to update both x and y for the system to be in a consistent state, you have a problem.
- sillysaurus3 11y agoIt will do what you just described. And what you described won't crash. If you use the int as an offset into raw memory, then sure, that will. But if you use it as an offset into a list, then it won't. At most it will cause an exception to be generated. That will cause the reader thread to die, because it was the code that caused the exception, but it still won't crash.
- wtetzner 11y agoRight, but I don't really see how that's freeing. A crash isn't good, but having your program be incorrect might be even worse. If the program crashes, you know it. But it might take some time before you recognize that your logic is wrong, which might cause all kinds of damage. So I don't think it frees you from thinking about concurrency at all.