Actors, Green Threads and CSP on the JVM
boundary.com
Actors, Green Threads and CSP on the JVM
1–10 of 49 posts
Re: Actors, Green Threads and CSP on the JVM
#2Very interesting article and analysis, although it would be nice if it explained what exactly a "Green Thread" is. From the article, I am guessing that a "Green Thread" is related to the lightweight low-level concurrency mechanism that he is referring to as the alternative to normal threads, but it is not exactly clear what that really means.
Re: Actors, Green Threads and CSP on the JVM
#3The argument seems to be that the actor model implementations on the JVM aren't all that fast and the language can't stop you from shooting yourself in the foot.
That's not really the issue as far as I'm concerned. Message-passing concurrency actually allows people be productive writing concurrent code that has a hope of working -- that is the main advantage. Occasionally things go wrong. Occasionally you need more performance and have to drop down to a lower level. But I can easily write a web service running on the JVM that gets 1000 requests/s per CPU with a bit of message passing concurrency. That's the point.
Heck, I don't even like the actor model -- I much prefer CSP -- but I'd attack it for other reasons (like lack of type safety).
Re: Actors, Green Threads and CSP on the JVM
#4Very interesting article and analysis, although it would be nice if it explained what exactly a "Green Thread" is. From the article, I am guessing that a "Green Thread" is related to the lightweight low-level concurrency mechanism that he is referring to as the alternative to normal threads, but it is not exactly clear what that really means.
A green thread is a "lightweight" thread, meaning a thread that is managed by a user level process, not by the OS. This main advantage is you avoid OS thread context switch time, which is comparatively very large. The disadvantages are:
- you have to balance load across true OS threads to take advantage of multiple CPUs. (You often pin an OS thread per CPU.)
- if you make a call to a blocking OS function you have no way to pre-empt your lightweight thread.
HTH.
Update: "you have to balance load" --> I mean the green thread library implementer. Users of a lightweight threading library typically don't concern themselves with this, though they might if performance becomes an issue.
Re: Actors, Green Threads and CSP on the JVM
#5I use Akka Scala/Java JVM actor framework daily, and it manages to get by without bytecode weaving. The lack of type safety is irritating, though.
Re: Actors, Green Threads and CSP on the JVM
#6I use Akka Scala/Java JVM actor framework daily, and it manages to get by without bytecode weaving. The lack of type safety is irritating, though.
It's very easy to mess this up though - either by blocking the thread or by capturing a reference to the mutable state of the actor in a closure.
Re: Actors, Green Threads and CSP on the JVM
#7Anyone using core.async knows how this article relates to it?
Re: Actors, Green Threads and CSP on the JVM
#8Anyone using core.async knows how this article relates to it?
The points about the JVM not being able to guarantee that your code won't block the thread apply; it's left up to you to do it. This doesn't come as any surprise to me, nor I would guess to most users of the library, so I'm not sure this is really that damning. Core.async doesn't use bytecode weaving or fork/join, so those criticisms don't specifically apply.
Re: Actors, Green Threads and CSP on the JVM
#9[deleted]
Re: Actors, Green Threads and CSP on the JVM
#10The argument seems to be that the actor model implementations on the JVM aren't all that fast and the language can't stop you from shooting yourself in the foot. That's not really the issue as far as I'm concerned. Message-passing concurrency actually allows people be productive writing concurrent code that has a hope of working -- that is the main advantage. Occasionally things go wrong. Occasionally you need more p…
Right, and when you "drop down to a lower level" to get more performance, the entire house of cards comes crashing down with bugs that are extremely difficult to debug.
The issue isn't actor model on a virtual machine-- erlang runs on a VM-- the issue is that the actor model is insufficient. You need pretty much most of OTP to build reliable, stable, concurrent systems.
This is why goroutines, everything on the JVM, etc are not going to work.
The sad thing is, I think the primary reason people are not using Erlang is they are afraid of the syntax, but even that reason is obliterated by the existence of Elixir (an even better language on the erlang VM)