This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
I'm relatively new to Scala, so please excuse this simple question ;-)
Every tutorial, article etc. describing Scala's concurrency features talks about the actor model. I'm wondering if this is the one and only concurrency paradigm in Scala?!? And moreover, can you address every needs for concurrent programming with actors?
The actor based model is the most prominent solution offered in Scala.
There are a few other approaches implemented in additional libraries.
Other approaches may gain prominence in the future. However, as of now
actor based model is the most popular.
Yes, you can address your concurrency need using actor. However, that does not
mean that is the only way it should be done. The immutability and functional aspects
combined with message passing makes quite a bit of sense. At the same time, I also
like, within reason, the transaction model of Clojure. I hope for that to gain some
acceptance and use within Scala in the future.
I think Venkat is talking about the concurrency paradigm "software transactional memory" which is used in the Clojure language, although it's not Clojure specific. But I'm not an expert on this. It sounds very interesting but from what I know it's currently a bit slow as it has do be done all in software until it gets integrated in modern CPUs for home computers one day.
I guess, that should be really possible to do with the power of Scala. Unfortunately (or luckily) from what I read Clojure has a really good performance. So I suspect that Scala would suffer from the same slow down when using transactional memory?!? But as I said, I have no practical experience so I can't even tell how slow "slow" could be...
Joined: Jan 28, 2008
Polymorphism was once very slow.
That's not the case any more. You
wouldn't reject the concept based on
an implementation. So I will not assume
Scala can't do better.
Also, general performance concerns are often
misleading. Knowing the real details,
we can design our apps to make good use of
Oh no, please don't get me wrong with this point, Venkat!
I definitely agree with you here. In my opinion good concepts for the future should never be abandoned because of some technical limitations at present which we are able to solve in the near future anyway. Regarding performance I'd say garbage collected memory is one prominent example for this. It has vastly improved and surely helped for the success of Java. And the technology is still improving today... The performance problems with transactional memory implemented purely in software was just one thing I read about in an article. But as I wrote above the idea behind it generally sounds very promising.
Joined: Oct 01, 2001
Venkat Subramaniam wrote:I was suggesting the former.
Thanks, Venkat. That's what I thought but I've learned over the years to check my assumptions.