Hacker News Reader

Comment by enneff | Hacker News Reader

> send a map over a channel, access it concurrently, and it will segfault

Not exactly. Go's maps may safely be read from multiple threads simultaneously, but writing at the same time as reading or writing will yield undefined behavior.

Go programs don't segfault like C programs. They typically panic, providing a descriptive stack trace of where the problem arose.

As I mentioned in my other thread, what you're describing are "thread safe data structures," which Go doesn't provide by default. We provide the fast and non-thread-safe data structures and let the programmer build the concurrency mechanisms around them (easily done with a lock or using goroutines/channels).

View on HN

"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