Hacker News new | past | comments | ask | show | jobs | submit login

Doesn't go just implement Hoare's communicating sequential processes, as does Erlang? They share the same inspiration.

You don't need to share state data between your goroutines if you don't want to either just like you don't have to use mnesia to share state between erlang processes if you don't want to.

I don't think you can really accuse go of being a cargo cult language either, Rob Pike has implemented CSP multiple times (http://swtch.com/~rsc/thread/).




Doesn't go just implement Hoare's communicating sequential processes, as does Erlang? They share the same inspiration.

Nope: The original Communicating Sequential Processes model[24] published by Tony Hoare differed from the Actor model because it was based on the parallel composition of a fixed number of sequential processes connected in a fixed topology, and communicating using synchronous message-passing based on process names (see Actor model and process calculi history). Later versions of CSP abandoned communication based on process names in favor of anonymous communication via channels, an approach also used in Milner's work on the Calculus of Communicating Systems and the π-calculus.¹

¹: https://en.wikipedia.org/wiki/Actor_model#Contrast_with_othe...


It is easy to accidentally share state between goroutines. For example, we wish to print out elements of a list:

    values := []string{"a", "b", "c"}
    for _, v := range values {
        go fmt.Println(v)
    }
Each of these goroutines shares the same variable v, so this code contains a serious race condition.


It may be easy, but it's not that easy.

    values := []string{"a", "b", "c"}
    for _, v := range values {
        go func(){fmt.Println(v);}()
    }
Does have a race condition.

    values := []string{"a", "b", "c"}
    for _, v := range values {
        go func(s string){fmt.Println(s);}(v)
    }
Does not have a race condition.


You're still shaving v here, we can just see from the snipped that the shared v isn't used inside the anon function. But I suspect what the GP meant by "easy" is not having to think about this sort of thing. Your solution is good when you know you need to do this, but it can't even happen in Erlang so it's not a "gotcha" to watch out for.


Sharing v isn't the problem. The problem occurs when v is evaluated.

The parent's post has no race condition, as v is evaluated before the goroutine starts.

The top example of my post has a race condition because there is no guarantee when v will be evaluated wrt to the loop.

The bottom example has no race condition because v is evaluated on every iteration and assigned to s, which is used by the goroutine at some point afterwards.


My point still stands: to fix this, you have to realize that (a) v could be shared here and (b) that sharing could be a problem. I suspect the first time most newbies get hit with a race condition here they're going to be beyond baffled.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: