Concurrency is not Parallelism (it's better) - A talk by Rob Pike

Simon commented on this talk on G+: https://plus.google.com/107890464054636586545/posts/dVowddBT...

The process isolation model that CSP provides is generally useful within languages with mutable state.

In particular, the Kilim library for Java uses "microthreads" (similar to goroutines) plus a linear ownership transfer system such that only one microthread owns a given object/object graph at a time, preventing concurrent state mutation while still providing mutable state. Sending an object from one Kilim task to another transfers ownership, and thus messages become the mechanism by which state is isolated at the process level.

Mutable state can be safe too. You just need the proper abstractions.

Since being schooled by other HN readers on parallelism vs. concurrency in the past, my way of distinguishing it:

Concurrency is a programming language issue, parallelism is a resource allocation issue.

EDIT: Well, this appears to be stated pretty clearly in the presentation, but I only got the presentation working after trying it for the 3rd time (in the 3rd browser).

_why?

Well that's the weirdest thing. I've seen this kind of thing before, so I guessed that <--> would work. But the page asks my browser to store information. If I ignore the question and just allow the query to continue to display at the top of the window, I can navigate fine. If I say "Not now," I'm stuck on whatever page I was on when I answered, and have to reload to be able to move again. Ubuntu 11.10, FF recent.

try spacechem

Yes, that is a typo. Goroutines are multiplexed to OS threads, but this is done transparently, you don't have to worry about it.

You can have tens of thousands of Goroutines without any problems.

Goroutines are threads though (in the sense of preemtively scheduled concurrent execution sharing memory), they just aren't OS threads.

I think the point he's trying to make is that if you make a blocking system call, it blocks the thread that goroutine is scheduled within, but other goroutines will not be blocked by this and will continue to execute.

This is not the case with many other (single-threaded) systems built exclusively around a god-loop that schedules coroutines. One coroutine making a blocking system call gums up the whole works.

To be fair, with lisps there's no real difference between a feature from a library and a feature provided by the language.

If you need to rely on C libraries, it seems to me the best use of Go is as a coordination language. Use it to distribute tasks that are then executed by isolated, shared-nothing C code.

> Does Google foresee a future entirely built in Go, the same way NeXT expected the world to evolve towards Objective-C?

Eventually, sure, why not?

Still you don't need your whole OS to be in pure Go to take advantage of Go's features, most Go systems are purely in Go as the stdlib is quite complete, but even then there is no issue linking with (most) existing C code if you need to (C code that does its own threading stuff obviously is more problematic).

Why does the whole world have to be built that way? If, the next time you do a new project start on a web app, your web app were built this way, then you would see the advantages of this approach in your web app.

If there are equivalent ways of designing for concurrency in Java or C# (or those ways are added to the language in the future), then you may be able to restructure existing Java and C# code bases to take advantage of this approach.

If you have 20 million lines of Cobol transaction processing code and there's no practical way of migrating your code base to use this methodology, then your 20 million lines of Cobol will keep running the same way they always have.

Unless I'm missing a point you're trying to make (certainly possible) there's no reason to think that this is an all or nothing approach.

Keep on truckin'. The situation is not necessarily hopeless, it just takes time to resolve. For example, see: http://halvm.org/wiki/

It may be a long time but there will someday be a world not built on C or C++. Probably within my lifetime. (Probably.)

It looks like a custom one, but it reminds me of "impress.js"

Software that predates the iPad, it seems.

If you didn't know about it, you might want to look at asciidoc: http://www.methods.co.nz/asciidoc/ (search for slidy)

I don't think you understood the slides. Go does run faster on multicore systems. It uses a configurable number of native threads to run the goroutines in.

This and that are different, languages like Go and Erlang use m:n mapping to map their m lighweight threads/processes onto n kernel threads (where n is usually the number of physical cores on the machine) to benefit from hardware concurrency.

But the presentation is about concurrency and parallelism not being the same thing, and more concurrency not necessarily leading to more parallelism.

> Don't make excuses for your language.

There's no excuse made.

> Just solve the problem!

There's no problem to solve. If you're asked to count from 1 to 100, you can't parallelize it: it's a purely sequential task, each step has a hard dependency on the previous step. So there is no possible parallelism.

But it is possible to do something else at the same time, or to have one process handling the counting and sending the current count to an other process printing it. That's concurrency: you've got two things running at the same time.