4 ms·
Cool. Can the concurrency guru's out there tell me what is the difference between the "Go Concurrency Pattern" and the Java SingleThreadExecutor? (http://docs.o
by noname123 13y ago
Cool. Can the concurrency guru's out there tell me what is the difference between the "Go Concurrency Pattern" and the Java SingleThreadExecutor? (http://docs.oracle.com/javase/6/docs/api/java/util/concurrent/Executors.html#newSingleThreadExecutor%28%29 http://docs.oracle.com/javase/6/docs/api/java/util/concurren...)
ExecutorService pipeline = ExecutorService.newSingleThreadExecutor();
FutureTask<String> step1 =
new FutureTask<String>(new Callable<String>() {
public String call() {
return "step1";
}});
executor.execute(step1); // execute single-step pipeline
step1.cancel(true); // interrupt the task
- enneff 13y agoThere is no "Go Concurrency Pattern" (singular). The article demonstrates some ways to use Go's concurrency primitives. Obviously there is a massive syntactic difference between your Java example and the equivalent Go code, but the other major difference that jumps out at me is that cancellation is baked into the Java library, whereas in Go the programmer determines how each of their pipeline stages should be shut down.
- crypto5 13y ago> Obviously there is a massive syntactic difference between your Java example and the equivalent Go code With Java 8 and lambdas, syntax will be much cleaner, i.e. you can write something like: executor.execute(() -> "step1");
- songgao 13y agoI guess an obvious difference is that Go has these stuff built into runtime and syntax, which makes those light-weight threads / tasks a first class thing. Furthermore, is there a way in "Java SingleThreadExecutor" and its related components that allow automatic scheduling tasks on different threads? For example, you are on a quad-core and you want to have 4 threads running together, with millions of tasks mapped to 4 threads and dynamically balanced.
- dack 13y agoI think one huge difference is that a channel in Go is a stream of data, in which each element can cause the consuming code to wait for new responses. In your example, the future can only return one bit of data. Afaik, what Go does is just an implementation of http://en.wikipedia.org/wiki/Communicating_sequential_processes http://en.wikipedia.org/wiki/Communicating_sequential_proces... which is also available in some other languages (Clojure is the one that comes to mind for me). In Java, I think a closer analogy is a http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/SynchronousQueue.html http://docs.oracle.com/javase/7/docs/api/java/util/concurren... which lets the producer and consumer threads automatically work in lock step as well.
- crypto5 13y ago> I think one huge difference is that a channel in Go is a stream of data, in which each element can cause the consuming code to wait for new responses. In your example, the future can only return one bit of data. In java you also can do something like: List<Future<Long>> futures = new ArrayList<>(); for(int i = 0; i < n; i ++) futures.add(some parallel execution logic); long count = 0; for(Future<Long> f: futures) count += f.get();
- jbert 13y agoI think the main difference is the way the language and runtime collaborate to schedule multiple events. Note the use of the 'select...case' in the example code. These slides go into some more examples: http://talks.golang.org/2013/advconc.slide http://talks.golang.org/2013/advconc.slide You end up with a really nice "actor model", where you have a goro which owns some state responding to incoming messages over channels and sending replies. Slide 24 gives the general structure, but it's a good read.
- jlouis 13y agoTo me, the major difference is that the Java solution gives you one solution. The Go solutions gives you the building blocks. The latter has the advantage you get to recompose the system in new ways, yielding greater flexibility. In Java, a better compositional framework is probably Erik Meijer's et.al's RxJava. Haskell also provides better compositionality due to it's functional structure and lazy evaluation semantics.