←back to thread

Go channels are bad

(www.jtolds.com)
298 points jtolds | 1 comments | | HN request time: 0.263s | source
Show context
Jabbles ◴[] No.11210740[source]
Effective Go has always said:

Do not communicate by sharing memory; instead, share memory by communicating.

This approach can be taken too far. Reference counts may be best done by putting a mutex around an integer variable, for instance.

https://golang.org/doc/effective_go.html#sharing

replies(3): >>11210862 #>>11210978 #>>11210990 #
poizan42 ◴[] No.11210862[source]
Reference counts are best done using interlocked increment/decrement primitives.
replies(2): >>11210871 #>>11211088 #
chrisseaton ◴[] No.11211088[source]
I wonder if there are any compilers which can replace

    mutex.lock { x++ }
With a 'lock xaddl x 1' instruction.
replies(4): >>11211325 #>>11211581 #>>11211703 #>>11212909 #
nly ◴[] No.11211325[source]
It's conceivable, if you made mutexes compiler/language intrinsic, but as long as you're calling pthread_mutex_lock, the compiler has to assume that that pthread library, which is linked dynamically, is interchangeable, and can do anything it likes to memory. That includes mutating x
replies(1): >>11213078 #
pcwalton ◴[] No.11213078[source]
That hasn't inhibited optimizations for a long time. Disassemble a call to printf("Hello world") in optimized clang output and look at what it turns into.
replies(2): >>11213389 #>>11214716 #
1. chrisseaton ◴[] No.11213389[source]
Yes if the library is covered by a standard just like the language is, then the compiler can make assumptions. Also threads are a language feature in C and C++ now.