Are Go maps sensitive to data races?
dave.cheney.net
Are Go maps sensitive to data races?
1–10 of 81 posts
Re: Are Go maps sensitive to data races?
#2"no, there is nothing wrong with Go’s map implementation."
"Getting your locking wrong will corrupt the internal structure of the map."
Ahem.
If you have a non-concurrency-safe map implementation in a language that's advertised as being good for concurrency, there is definitely something wrong.
Re: Are Go maps sensitive to data races?
#3"no, there is nothing wrong with Go’s map implementation." "Getting your locking wrong will corrupt the internal structure of the map." Ahem. If you have a non-concurrency-safe map implementation in a language that's advertised as being good for concurrency, there is definitely something wrong.
The two sentences are consistent once you read that Go maps are not designed to be safe for concurrent access.
Re: Are Go maps sensitive to data races?
#4"no, there is nothing wrong with Go’s map implementation." "Getting your locking wrong will corrupt the internal structure of the map." Ahem. If you have a non-concurrency-safe map implementation in a language that's advertised as being good for concurrency, there is definitely something wrong.
> Ahem
Maps are not concurrency-safe, you know what else isn't? Integers, floats, pointers, structs. And not only in Go, but in pretty much almost all languages with mutable state, like C and C++.
The map implementation in Go is consistent with the rest of the language, plus it allows for great performance under some rather common scenarios.
But I guess it's fashionable to snark on message boards than rather understand all these facts.
Re: Are Go maps sensitive to data races?
#5"no, there is nothing wrong with Go’s map implementation." "Getting your locking wrong will corrupt the internal structure of the map." Ahem. If you have a non-concurrency-safe map implementation in a language that's advertised as being good for concurrency, there is definitely something wrong.
The two sentences are consistent once you read that Go maps are not designed to be safe for concurrent access.
Java's (pre-concurrent) HashMaps aren't designed for concurrent access.
Do you know what they do? They throw a ConcurrentModificationException.
Do you know what they don't do? Silently corrupt themselves.
Re: Are Go maps sensitive to data races?
#6"no, there is nothing wrong with Go’s map implementation." "Getting your locking wrong will corrupt the internal structure of the map." Ahem. If you have a non-concurrency-safe map implementation in a language that's advertised as being good for concurrency, there is definitely something wrong.
> Ahem Maps are not concurrency-safe, you know what else isn't? Integers, floats, pointers, structs. And not only in Go, but in pretty much almost all languages with mutable state, like C and C++. The map implementation in Go is consistent with the rest of the language, plus it allows for great performance under some rather common scenarios. But I guess it's fashionable to snark on message boards than rather understa…
I apologise for expecting better of language designers. After all, the solutions to these sorts of issues has only been around for a couple of decades. Far too soon.
Re: Are Go maps sensitive to data races?
#7"no, there is nothing wrong with Go’s map implementation." "Getting your locking wrong will corrupt the internal structure of the map." Ahem. If you have a non-concurrency-safe map implementation in a language that's advertised as being good for concurrency, there is definitely something wrong.
The two sentences are consistent once you read that Go maps are not designed to be safe for concurrent access.
Yeah, but the parent's phrase was:
"If you have a non-concurrency-safe map implementation in a language that's advertised as being good for concurrency, there is definitely something wrong".
If we accept his premise, then the fact that "they wasn't designed for that" is no excuse. It's like selling a kids toy that has tiny choke-inducing parts. In that case, just saying: "It wasn't designed to be eaten by kids" is not really an excuse.
Re: Are Go maps sensitive to data races?
#8Earlier quoted context omitted.
The two sentences are consistent once you read that Go maps are not designed to be safe for concurrent access.
Java's (pre-concurrent) HashMaps aren't designed for concurrent access. Do you know what they do? They throw a ConcurrentModificationException. Do you know what they don't do? Silently corrupt themselves.
From HashMap JavaDoc:
Note that the fail-fast behavior of an iterator cannot be guaranteed
as it is, generally speaking, impossible to make any hard guarantees in the
presence of unsynchronized concurrent modification. Fail-fast iterators
throw ConcurrentModificationException on a best-effort basis.
Therefore, it would be wrong to write a program that depended on this
exception for its correctness: the fail-fast behavior of iterators
should be used only to detect bugs.
So even while Java tries to find concurrency bugs, it does not promise it.
Re: Are Go maps sensitive to data races?
#9Earlier quoted context omitted.
Java's (pre-concurrent) HashMaps aren't designed for concurrent access. Do you know what they do? They throw a ConcurrentModificationException. Do you know what they don't do? Silently corrupt themselves.
From HashMap JavaDoc: Note that the fail-fast behavior of an iterator cannot be guaranteed as it is, generally speaking, impossible to make any hard guarantees in the presence of unsynchronized concurrent modification. Fail-fast iterators throw ConcurrentModificationException on a best-effort basis. Therefore, it would be wrong to write a program that depended on this exception for its correctness: the fail-fast beha…
Not to mention that Go does have the race detector, which does the same thing in this case (although it does so much more in general).
Re: Are Go maps sensitive to data races?
#10Earlier quoted context omitted.
The two sentences are consistent once you read that Go maps are not designed to be safe for concurrent access.
Java's (pre-concurrent) HashMaps aren't designed for concurrent access. Do you know what they do? They throw a ConcurrentModificationException. Do you know what they don't do? Silently corrupt themselves.
That check probably comes at a performance cost that the Go standard library designers found unacceptable. You don't even need to be modifying it concurrently to read inconsistent state, it's enough to write on one thread and read on another, while the map is updating internally. So in order to prevent inconsistent reads you would have to check for concurrent access on all reads. The .NET BCL Dictionary is just like the Go one: it does no checking for you and will silently corrupt or return an inconsistent view if you access it concurrently.
The whole reason there are two implementations of the dictionary (Concurrent and Non concurrent) is that the performance cost of the concurrent implementation is too high to carry for the non-concurrent one. Depending on the cost of checking for concurrent access, a lot of the gain of using a simpler non-concurrent one could be lost.