This (and pretty much all the other libraries) misses the point of Go/CSP channels completely. The select/alt statement. Channels are just queues. Queues are useful in any language. The power and ease of use of Go concurrency primitives don't come from channels and goroutines, it comes from the select statement.
Go is not really CSP anymore. The scheduler pre-empts.
You're right regarding this (pointless?) wrapper around Doug Lea's queues. If the OP really wants the kudos for doing CSP on Java, s/he'll need to tame the NIO selectors and no doubt sprinkle a little ASM magic dust on it as well.
Closest thing we have is Kilim (which is just simply awesome.)
Actually, the closest we've got is Quasar[1] (I'm the main author). It's got true lightweight threads (goroutines), as well as selectable channels. On top, it's got actors, complete with selective receives and hot code-swapping.
It is much more actively maintained than Kilim, more general, and has better performance to boot. Also, Quasar fibers interoperate very nicely with plain threads. Blocking operations (such as channel receive) block the thread if you're running in a plain thread, and the fiber if you're running in a fiber.
In fact, we've even had time-sliced preemptive scheduling, which we've taken out because it didn't give performance benefits to fibers that block a lot, and for computations that don't, there's full blown threads (which Go doesn't have).
I found Kilim to be an overkill for the most of my use cases. Instead I recommend checking out jetlang, https://code.google.com/p/jetlang/.)
(
This implements message based concurrency, similar to Scala. I am using this in production code without any issues.I found this easier to implement than Kilim and delivers equivalent functionality
I'm not an expert at Go but what is the power that select gives. Don't higher order channel structures like multiplexing achieve something similar. Can you throw more light on this?
The 'select' statement does more than just multiplex (and it doesn't really multiplex since you can't do it over a slice of channels). It allows blocking on any one of a set of send or receive operations. This is similar to the select(2) system call in BSD
Thanks, the analogy to the system call helps heaps in my understanding of the intent. It's value wasn't clear to me when I was debating it's inclusion in the library. I'll have a deeper look and see how best I can include something similar in the library. Sadly, I doubt the interface for it would be as elegant as the one Go has.
As described by Carl Hewitt, the inventor of the Actor model:
- CSP uses named channels (coincidentally called channels in Go) with anonymous processes (goroutines in Go)
- Actors are anonymous channels (mailbox addresses) with named processes (actors).
Carl Hewitt states that CSP was created to create a concurrency model around algebra and having named channels was the only way to accomplish that due to the constraints of algebra.
The Actor model's foundation is in physics. Here's an excellent video of Carl Hewitt giving an off the cuff explanation of the Actor Model[0], and some notes I took while watching it[1] (please add more notes if you can, I get confused about this topic constantly).
Another important note is that there are many different implementations of CSP but only one implementation of the Actor model.
Channels live at a lower level. Usually when you create a channel you share it between multiple goroutines: It acts exactly like a pipe, and are transparent to what's inside. Moreover, goroutines sending to and receiving from a channel don't know (and don't need to know) what's on the other end.
Actors are more like a combination of a channel and a goroutine: when you send something to the actor, you know what the other end is and you know what it does with messages.
Actors induce a certain paradigm for your application, and I believe Go just wants to give you the tool to build whatever you want. Having channels allows using the Actor paradigm, the other way is not as easy/lightweight.
> Actors are more like a combination of a channel and a goroutine: when you send something to the actor, you know what the other end is and you know what it does with messages.
I don't think this is the case at all. When sending a message to an address you don't know how many actors are behind that address, and even further you don't know how many addresses an actor has. Actors and addresses have a many-to-many relationship.
I think the power of the Actor model is essentially putting your faith in the system and not caring about when messages get handled, or what order they get handled in - it's just knowing that the message will get handled.
The bounded nature of channels tie the communicating processes together more intimately. As a result channels are very good for coordination between processes. Both do a good job of communication between concurrent processes/threads.
What is a case in which you'd want pass by value in a queue? I mean sometimes you're forced to pass by value, but if you have the option of pass by reference, why would you choose by value?
Maybe I've been doing this stuff too long, but it's not all that hard to make an object safe for concurrency. But, I am probably missing some context.
While I agree it's not hard to make an object safe for concurrency, knowing how to do it effectively is another matter. In an organization or team where there are engineers at all levels of familiarity with java, getting concurrency right is a PITA.
Additionally in this context, the very basis of the channel mechanism is "share state by communicating, don't communicate by sharing state". Also pass by value lends itself well to remoting if I choose to go in that direction.
There is /no/ silver bullet for the complexity of concurrency. If in a large team of uneven experience every developer is expected to address concurrency issues, then the problem is architectural.
> "share state by communicating, don't communicate by sharing state"
The elegance of this approach is very clear. But note that even in Go, when performance is critical, traditional mechanisms of locks and shared memory objects are used. (The fact that such constructs are even provided in the language should be informative to you.)
I see. I'm afraid in a mutable world that causes all kinds of serialization issues and unpredictable performance. Java developers are not used to knowing their object graphs very well.
Spring integration project has similar concept of channels and you can use declarative model to connect channels and components & of course can do much more. What are any differences if you have context of Spring Integration?
It's flipkart's OpenSource software org on github to incubate projects that developers drive and graduate them to fully sponsered, flipkart opensource projects.
