views:

927

answers:

4

I've been reading a lot about how Scala and Erlang does lightweight threads and their concurrency model (actors).

However, I have my doubts.

Do Scala and Erlang use an approach similar to the old thread model used by Java (green threads) ?

For example, suppose that there is a machine with 2 cores, so the Scala/Erlang environment will fork one thread per processor? The other threads will be scheduled by user-space (Scala VM / Erlang VM ) environment. Is this correct?

Under the hood, how does this really work?

+1  A: 

Scala uses the underlying Java thread implementation, which uses native threads.

Can't say about Erlang.

dave
hi dave,i know that , the newest JVM use only native threads, but there is a problem to scala be scalable using only native threads. So, some articles that a i read said that a pool of threads ( workers ) are used to the Scala "Concurrency environment", and the ideia is use the less possible java threads ( native threads ).
CHAPa
+16  A: 

Erlang is using user-space multitasking, tasks run until they block or until they have used up their share of 'reductions'. A reduction is vaguely defined as a unit of computation.

Up until the SMP scheduler, there was just one kernel thread taking runnable tasks. With SMP scheduling you have several kernel threads taking tasks, and thus executing code in parallel on multi-core machines. The number of scheduler threads should match the number of cores. See the -smp [enable|auto|disable] switch in the erl manpage.

There has also been a pool of kernel threads for loadable drivers to execute blocking system calls in. This is called the async thread pool. See +A size in the erl manpage.

Further reading

Christian
@thanks Christian. So the user-space multitasking scheduler will elect some "thread object" to be executed by the OS Thread. right ?
CHAPa
I can't describe it much better than the pdf from EUC'08 that I linked to. I believe that the current OTP release now have multiple run-queues as described in section 5.2, we live in the future.
Christian
No, an OS thread runs an erlang scheduler which explicitly handles processes and their scheduling. That is why you seldom have more than one thread per core, at least for running the erlang code, it is not needed. OS threads are usually way to heavy to be used for erlang processes.
rvirding
+3  A: 

For recent information about Erlang implementation details check fresh talk (slides).

Hynek -Pichi- Vychodil
cool, nice talk. Thanks a lot
CHAPa
+12  A: 

Scala 2.8 uses Java thread pools. The lightweight actors (Reactor) and the heavier actors in lightweight mode (react {...}) don't take their own thread; rather, when they have a message, they take a thread until they're done processing the message, then give back the thread and don't run at all until the next message hits.

This article gives a decent description of Actors in 2.7; 2.8 is not that different.

Rex Kerr
@Rex, but, to be scalable, scala cant use only java thread ( native OS Thread ), it must be able to create a environment where a new kind of thread be available, like a green thread. Imagine, 100 actors, and each actor using a java thread, this is not lightweight thread, because the switch thread context isn´t too light. right ?
CHAPa
That's sort of correct. The switches are not as lightweight as Erlang. You almost always can avoid having 100 actors on 100 threads (by having them react to messages rather than constantly running), so you still have the non-lightweight Java threads underpinning the whole affair, but lighter-weight message consumption (since messages for multiple actors can be processed by one thread). Because of this architecture, you can scale to very many react-style actors without running out of OS threads, but it is not as amazingly scalable as Erlang. (Search for "thread ring benchmark shootout"...)
Rex Kerr