Hacker News Reader

Comment by ootachi | Hacker News Reader

"Undefined behavior" is the problem here. In Java, you can create data races, but you can't cause memory errors.

What do you mean ? I you don't use synchronization protection when you access your structures from different threads, you'll have the same inconsistency in your data. Using the explicit Mutex of Go doesn't seem so different than creating an object on which synchronizing your blocks as you do in Java.

Or do I miss something in your comment ?

EDIT : In my opinion, a program that doesn't crash and goes on running with inconsistent data structures is mainly hiding a failure which will appear in a worse way later (for example when those data will be used). To fail fast is often more secure. But my opinion may be based on the fact that I see too many java programs which seem to work but that nobody can touch because they're just in the lucky state where bugs don't surface too much.

Mutating a hash map in Java while another thread reads it won't cause bad things like:

(a) memory you don't have access to to be read;

(b) other threads to crash;

(d) the GC to crash;

and so on. The Java world is still in a consistent state. In a security-oriented world, this is important.

To the reply: It's a bit pedantic for me to say this, I know, but that's still "a consistent state". Basically, a Java program can't do anything it wouldn't otherwise be able to do by modifying a hashmap concurrently. Java programs can go into infinite loops. They can't access uninitialized memory.

Not entirely true. It's possible to have threads enter infinite loops if you don't synchronize properly: http://stackoverflow.com/questions/1003026/hashmap-concurren...

Reply on news.ycombinator.com