Co Routines, Go Routines and Concurrency

I have been reading about concurrency recently, and more specifically about lightweight threads of the sort that have been popularised by the Go Programming Language.

Co-routines have been discussed for a while, and were implemented as async/await in C# before Go brought them to the attention of open source and Java developers. FOSS and Java developers tend to ignore the innovations that C#/.NET have implemented which is a shame. Perhaps that will change now that C# is open source.

Co-routines are basically green threads or user level threads. The idea is that a more lightweight alternative to full O/S backed threads is needed in order to support the level of concurrency needed to support modern web-scale applications. O/S backed threads are expensive to create and context switching between them is expensive too. An application can create tens of thousands more green threads than real threads as demonstrated by Go programs that recursively create millions of go-routines and iterate through them in milliseconds. Try doing this with Java Callables/Tasks :

package main

import (
"fmt"
)

// create one million goroutines/channels and pass a count
// through them
func main() {
sum := make(chan int)

go plusone(sum, 1000000)

total := <- sum
fmt.Println(total)
}

func plusone(returnchan chan int, start int) {
if start == 1 {
returnchan <- 1
} else {
newchan := make(chan int)
go plusone(newchan, start - 1)
returnvalue := <- newchan
returnchan <- returnvalue + 1
}
}

OK, for this particular example you’d probably use Streams in Java 8 but you get the point.

The closest thing that I have seen is Fibers that use instrumented code to insert suspension points in Java bytecode with help from annotation based hints from the developer regarding which parts can suspended and resumed. There is nothing built-in to the Java API/runtime that matches goroutines.

The problem that both Java Tasks and Fibers face however is blocking calls that will block the thread on which the respective task/fiber is executing. So the sweet spot is a non-blocking API that allows the calling task/fiber to be suspended until the API returns. Or does anyone know any different?