My disorganized thoughts on the computer language “GO”.
Go has a novel relationship with threads and consequently does its own.
As with most languages most offered tutorials teach how to write “Hello World” which provides no insight as to why you might want to learn the new language.
This page speaks of GO’s “concurrency primitives” which is what presumably concerns us.
I want to understand why the Go designers think that their patterns are useful.
I quote a few sentences which include the word “concurrency”:
- [GO’s] concurrency mechanisms make it easy to write programs that get the most out of multicore and networked machines, ...
- Concurrency is the key to designing high performance network services.
- Go's concurrency primitives (goroutines and channels) provide a simple and efficient means of expressing concurrent execution.
- In this talk we see how tricky concurrency problems can be solved gracefully with simple Go code.
I recommend this talk by Google’s Rob Pike which emphasizes that Go is not about parallelism.
Many issues emerge in this talk.
About 5:30 he speaks of “writing files by name” but “writing channels by descriptor” and that the later is a means of indirection.
About 9:45 he says “goroutines are multiplexed onto threads”.
I suspect that by “threads” he means “kernel threads” and that the kernel is unaware of goroutines, just as it is unaware of subroutines.
This would mean that a particular goroutine is always attached to the same thread.
About 12:40 he has described channels but that they do not buffer and are thus a blocking operation.
The primitive channel creator creates a single value for both ends of the channel.
This seems awkward to me.
One of the tutorials is a toy web crawler.
That is certainly a concurrent application as you must probably be in the midst of visiting several sites at once.
Semantics of Multiprocessing
C does not try to improve on the semantics of running several processors in the same mutable memory.
It is entirely between the programmer and either the kernel or the hardware itself.
C is a high level assembler.
Languages such as Go aspire to insulate the programmer from this level of detail.
Go advises against and perhaps prevents sharing mutable memory.
The Go channel is supposed to serve all dynamic inter-thread communication purposes.
I think that Go assumes that programs are free to use foreign kernel services to interact with the outside world, not free to indulge in such dangerous activity as the fork system call.
It is clear that someone will step over this barrier while attempting to hold to some set of principles.
I have not seen those principles yet.
I don’t know whether the Go thread primitives are MP safe, and even that would not suffice.
Recall the havoc over which library routines were “thread safe”.
Here is the closest thing I can find on how to get to multiprocessing.
The comments there are the best documentation I have found.
A nice use