Are Go maps sensitive to data races?

Post by tomp » Mon, Dec 07, 2015, 2:41 PM UTC

chrisseaton wrote: post #65

tomp wrote: post #64

Earlier quoted context omitted.

So... the second thread needs to wait for the GC in order to modify the map concurrently? I mean, it is an optimization for the most common case (single-threaded access), but it imposes a quite high penalty for concurrent access... Although I could imagine a similar "signaling" mechanism, where each thread would periodically read a single snychronized variable, to check if there's any additional "re-synchronisation"…

> So... the second thread needs to wait for the GC in order to modify the map concurrently? No nobody needs to wait for a GC, but we use the same mechanism that the GC does. > Although I could imagine a similar "signaling" mechanism, where each thread would periodically read a single synchronised variable And that's how the GC already works. Except instead of a variable normally a 'test' instruction is used on a page…

Post by khgvljhkb » Mon, Dec 07, 2015, 3:01 PM UTC

muraiki wrote: post #69

khgvljhkb wrote: post #50

Golang devs should have a look at Clojure and it's `core.async` library. It works very similarly to Go (heavily inspired by the good stuff), but all data structures are persistent, meaning you will never have problems with concurrent mutations (because there there are no mutations in the API, only internally). I recommend Go users to install the boot utility, and playing around with Clojure & core.async. These commun…

It's been a while since I used Clojure, so I apologize if what I'm saying is wrong or out of date. Having used both Clojure and Go there are some significant differences in how coroutines work in each. For instance, in Go making a blocking system call inside of a goroutine "just works" as Go will create additional goroutines as necessary. But if you do the equivalent in Clojure, you risk thread starvation. "However i…

Post by astrafoo » Mon, Dec 07, 2015, 5:25 PM UTC

alkonaut wrote: post #53

grabcocque wrote: post #47

Earlier quoted context omitted.

They're really not though. Java has ConcurrentHashMap and isn't slow. Clojure has its persistent HashMap and it isn't slow. Scala has, TWO (?) concurrent hash maps in its core and neither is slow. You know, two thirds of the way through the second decade of the 21st century, it's okay to spend a few cycles not corrupting your data structures.

There are both memory and performance considerations. For a server/db web application this may not be a problem, but for e.g. some logic in a game engine that runs every frame on a mobile device, then using 16 extra locks per map for example isn't a good idea. Nor is having 5% performance overhead. I can agree with an argument that thread-safe should be default and specialized/fast collections should be optional thou…

Post by dang » Mon, Dec 07, 2015, 8:24 PM UTC

grabcocque wrote: post #17

I'm increasingly convinced that Go is the new PHP, designed and used by the kind of people who know just enough to be incredibly dangerous to themselves and everyone else they touch.

Post by Matthias247 » Mon, Dec 07, 2015, 10:53 PM UTC

chrisseaton wrote: post #34

alkonaut wrote: post #13

Any data structure that isn't explicitly designed for concurrent access will not work when used concurrently. Since a concurrent map (aka. Dictionary aka. Hashtable) is a lot more complex and slow than a non concurrent one, it's very very unlikely that Go would ship with its standard map type being a concurrent one. It would be a huge waste. More likely there is a separate concurrent map type. It's exactly the same i…

> Since a concurrent map (aka. Dictionary aka. Hashtable) is a lot more complex and slow than a non concurrent one, it's very very unlikely that Go would ship with its standard map type being a concurrent one. It would be a huge waste. We should develop a system where maps are unsynchronised by default, but when you access them from a second thread they are then converted transparently by the runtime to a thread-safe…