Java V Scala from a concurrency Perspective

I'm starting my last year's project now I will study concurrency methods from the perspective of Java and scala After coming out of the Java concurrency module, I can see why people say that the shared state thread method is difficult to reason Because of the non deterministic way Java threads run, you need to worry about critical parts and risk race conditions and deadlocks In 1.5, this reasoning gained some clarity, but it was still very clear

In the first view, Scala seems to remove this complex reasoning through the actors class This enables programmers to develop concurrent systems from a more sequential perspective and easier to conceptualize However, for this positive side, do I correctly say that there are some shortcomings? For example, suppose we want to sort a large list in two cases - create two threads in Java, split the list into two, worry about key parts, atomic operations, etc., and go to code Using Scala, because it's "no sharing", you actually have to pass list / 2 to two actors to perform sorting, right?

I think my question is, is the price you pay for simpler reasoning the performance overhead of having to pass collections to your actors in scala?

I am considering doing some benchmarking on this effect (selective sorting, quick sorting, etc.) But because one is functional and one is necessary - I won't compare apple with apple from an algorithmic point of view

I really appreciate any of your ideas mentioned above. Give me some ideas to get me started Thank you.

Solution

The advantage of scala is that it can use Java for concurrency if necessary All Java classes are available

Therefore, it actually boils down to the difference between a model and a module. In the model, threads have concurrent access to variable variables, while there are stateful actors in the model. They send messages to each other but do not peep inside each other And you're absolutely right. In some cases, you have to weigh performance in order to easily get the right code

I usually find that, as a rough rule of thumb, if you spend a lot of time waiting for the lock to open, use the Java model, and there is no clean way to separate the work, in order to avoid everyone waiting for the resource, and if you perform a quick switch between threads, the Java model is much better than the actor model, in which the actor sends the "I've finished" message back to the supervisor, Then the supervisor sends out "this is a new work!" Messages to existing non - busy actors Sorting algorithms, depending on how you imagine them, can fall into this category very much

For most other things, the performance loss associated with actors is not what I see If you can think of your problem as a lot of passive elements (i.e. they only need time when they receive a message), actors can expand particularly well (millions are available, but only a few can work at any particular time); For threads, you need some extra internal state to track who should do what, because you can't handle so many active threads