#Learning concurrency in go

14 messages · Page 1 of 1 (latest)

winter ravine
#

can you give an example of something that's confusing you

#

I've never heard the given quote before. I suspect what they mean is that rather than sharing memory between two goroutines, you can often achieve the same effect by communicating the changes in the memory they both care about through channels. I am somewhat guessing

winter ravine
#

if you can give something they're doing in the tutorial that you don't understand, send in what they're doing and maybe I can help explain what's happening

#

I'm not really familiar with the getName(). Someone else can probably answer this better than me.

#

so first u need to start the goroutines before sending thru the channel

#

second, if u have two goroutines that are reading from the same channel, if one of the goroutines takes something from the channel, the other one will no longer be able to take it as well. the channel removes something once it is read

#

I would say generally you shouldn't do logic with a goroutine based on its name. the logic should be done in the goroutine.

#

here is a working version of the example you gave

#

func main() {
    messageChannel := make(chan string)
    messageRaw := "hello"

    go f(messageChannel)
    go g(messageChannel)
    messageChannel <- messageRaw

    time.Sleep(time.Second * 8)
}

// IK WaitGroup is better than Sleep.
func f(message chan string) {
    time.Sleep(time.Second * 2)
    x := <-message
    fmt.Println(x + " from main() in f()")
    message <- x
}

func g(message chan string) {
    time.Sleep(time.Second * 3)
    fmt.Println(<-message + " from f() in g()")
}
#

here, f() will take from the channel, read it, then send it again, and g() will then catch it

#

the sleeps here are important. this is not guaranteed to work if f() and g() are sleeping the same amount of time

#

edited for maybe some clarity

#

Good luck

#

mfw I tell someone I can't answer the question and they still get mad