Erlang Multi-process and multithreading:In Erlang development, the smallest execution unit we face is the process, and of course this process is not a process at the system level, nor is it a thread. It is a process that is based on the Erlang runtime system. So how does Erlang's multi-process become multi-threaded at the system level and then processed by multi-core processors? In fact, every time we launch an Erlang VM, we actually launch the emulator +erlang runtime system. Each Erlang runtime system initiates n process schedulers, each of which is a separate operating system thread. This scheduler processes a process pool, which is a m erlang process. This means that the Erlang process maps to the operating system thread in a 1:m way. Since each scheduler is an operating system thread, the Erlang process that can run in parallel can have a maximum of M. Although there are m processes within a process pool, processes within the same pool are still running as if they were the same scheduler as all previous processes. And on top of that, processes can migrate between process pools to maintain load balancing on the available schedulers.
single-process and multi-threaded for Erlang programs:Each time you start an Erlang VM, you start a process that includes many threads, most fundamentally including the Erlang runtime system and the threads created by the emulator. If you also run an Erlang program on that virtual machine, it is possible for ERTs to create n threads for your application. The number of these threads is related to the parameters set when the Erlang VM is started and its own hardware environment. So multi-threaded applications on multi-core multi-threaded CPUs will naturally be reasonably allocated to different processors to execute, which makes good use of multi-core multi-threaded resources. The NON-SMP supported Erlang VMs have only 1 schedulers running in the main processing thread. The scheduler takes out the Erlang processes and IO tasks that can run from the run queue (run-queue) and does not need to lock any data because only one thread accesses them.
Erlang VMS with SMP support can have one or more schedulers, each running in one thread. The scheduler removes the Erlang process and IO tasks that can be run from the same public run queue. All shared data structures in an SMP VM are protected by locks, and the running queue is such a lock-protected data structure.
Starting with OTP r12b, if the operating system reports that an SMP version of more than 1 CPUs (or CORE) VMs is automatically started, the same number of schedulers is started based on the number of CPUs or cores.
You can see which parameters are selected by the first line that you print from the Erl command. For example:
Erlang (BEAM) emulator version 5.6.4 [source] [Smp:4] [asynch-threads:0] .....
where "[Smp:4]" means that an SMP VM runs 4 schedulers.
The default value can be replaced with "-SMP [Enable|disable|auto]", Auto is the default. If SMP is enabled (-SMP enable), the number of schedulers that you want to set can use "+s number" (1 to 1024)
Note 1: The scheduler that runs more than the CPU or the total number of cores does not have any elevation.
Note 2: The number of CPUs or cores that a process can use in some operating systems can be limited. For example, in Linux, the command "Taskset" can implement this function. Erlang VMs can now only detect the total number of CPUs or cores, regardless of the mask set by "Taskset". That's why, for example, it might appear (already there) even though the Erlang VM runs 4 schedulers, it uses only 2 cores. The OS is limited because it takes into account the mask set by "Taskset".
The scheduler for each Erlang VM runs on an OS thread and is the OS that determines whether the thread executes on a different core. Generally speaking, the OS handles this problem well and ensures that threads run on the same core during execution.
Erlang processes are run by different schedulers because they are removed from a public run queue and run by the first available scheduler. Citation: http://bbs.chinaunix.net/thread-4091298-1-1.html http://blog.sina.com.cn/s/blog_4e928b170101b3bq.html
Erlang process vs. operating system threads
