3 ms·

Actually, I'd rather my program just crash at the point of use than silently corrupt my data. First, my existent data will be preserved, and after fixing the is

Actually, I'd rather my program just crash at the point of use than silently corrupt my data. First, my existent data will be preserved, and after fixing the issue I can rerun the operation. Second, I will get a clear crash that immediately tells me where the problem is, instead of getting garbage output that I have no idea where it sourced from. Oh, and since this is a threading problem, it's probably even transient data corruption.

kbenson 10y ago
That's not how threads work. Without thread safety mechanisms, you don't get occasional data corruption or the occasional crash, you get both, but often not at the same time. Occasionally data will be written out of order. Occasionally there will be enough weirdness you can have a crash. How often you get one or the other depends on the algorithms in use. Lock safe methodologies can prevent the crash, and if designed specifically for the data in question and the data structure supports it, can possibly ensure no corruption. Given with strings you probably have data corruption no matter what, do you want crashes on top of that or not?
- jdmichal 10y ago
  > Lock safe methodologies can prevent the crash, and if designed specifically for the data in question and the data structure supports it, can possibly ensure no corruption. Which was the entire point of my post. "Thread-safe" does not guarantee "usage-safe", and using them interchangeably is a fallacy. If the synchronized StringBuffer does not provide the guarantees you need anyway, there's no point in paying the cost of using it. > Given with strings you probably have data corruption no matter what, do you want crashes on top of that or not? I just said that, yes, I would rather the program crash than silently corrupt data. I would rather it crash 100% of the time, but I'll take intermittent crashes instead. A crashed process can be restarted; it's very much harder to fix data once corruption hits. And if data corruption hits anyway, at least if I also have a crash I have an idea of where to look for the issue.

kbenson 10y ago

That's not how threads work. Without thread safety mechanisms, you don't get occasional data corruption or the occasional crash, you get both, but often not at the same time. Occasionally data will be written out of order. Occasionally there will be enough weirdness you can have a crash. How often you get one or the other depends on the algorithms in use. Lock safe methodologies can prevent the crash, and if designed specifically for the data in question and the data structure supports it, can possibly ensure no corruption. Given with strings you probably have data corruption no matter what, do you want crashes on top of that or not?

jdmichal 10y ago
> Lock safe methodologies can prevent the crash, and if designed specifically for the data in question and the data structure supports it, can possibly ensure no corruption. Which was the entire point of my post. "Thread-safe" does not guarantee "usage-safe", and using them interchangeably is a fallacy. If the synchronized StringBuffer does not provide the guarantees you need anyway, there's no point in paying the cost of using it. > Given with strings you probably have data corruption no matter what, do you want crashes on top of that or not? I just said that, yes, I would rather the program crash than silently corrupt data. I would rather it crash 100% of the time, but I'll take intermittent crashes instead. A crashed process can be restarted; it's very much harder to fix data once corruption hits. And if data corruption hits anyway, at least if I also have a crash I have an idea of where to look for the issue.